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This Handbook establishes the detailed policies and processes for 
implementing NMI 7120.4, "Management of Major System Programs and 
Projects". It constitutes a comprehensive source of the specific 
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CHAPTER 1 


OVERVIEW 


1. REFERENCE 

NMI 7120.4, "Management of Major System Programs and 
Projects . " 

2. PURPOSE 

The purpose of this Handbook is to establish the detailed 
policies and processes for implementing NMI 7120.4. It is 
intended to support accomplishment of program and project 
objectives on schedule and within budget by providing 
specific program/project planning, review, approval and 
implementation policies and processes for assuring: 

- comprehensive definition (technical and management) , 

- adequate technology validation, 

- maximum annual funding stability, 

- simple organizational structures, 
realistic cost estimates, 

- realistic schedules, 

acquisition strategies to promote cost containment and 
shorter acquisition timelines, and 

- adequate mechanisms to assure control of approved 
program/project baselines. 

3. APPLICABILITY AND SCOPE 

a. This Handbook applies to NASA Headquarters, field 
installations, and the Jet Propulsion Laboratory. 

b. This Handbook applies to program/projects for the 
purpose of development and operation of a major system, 
as detailed in NMI 7120.4. Program Associate 
Administrators (PAAs) shall determine how these 
policies and procedures should be tailored, and 
selectively applied, to non-major systems consistent 
with their size, complexity and sensitivity. 

4. ORDER OF PRECEDENCE 

NMI 7120.4 and this Handbook rank first and second in order 
of precedence for providing policies and processes for 
managing major programs/projects, except when statutory or 
regulatory requirements override. 


1-1 



5. USE OF "SHALL" 

This Handbook uses "shall" to convey direction, i.e., 

"shall" statements are used for those implementing policies 
or processes that are mandatory. This Handbook uses "may," 
"will," "should," or other permissive words to convey 
guidance or recommendations, i.e., statements with words 
other than "shall" are used for those implementing policies 
and processes that are non-mandatory. 

6. DEFINITIONS AND ACRONYMS 

The definitions of terms and the listing of acronyms used in 
this Handbook are presented in Appendix B. 
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OVERVIEW /EXECUTIVE SUMMARY 


1. POLICIES 

a. Project T.i fe Cycle . NASA has adopted the five-phase 
project life cycle illustrated in Figure 1-1 as the 
framework for the comprehensive management and 
progressive decision making associated with Project 
Formulation and Implementation. This standard life 
cycle framework facilitates the orderly translation, 
consistent with Agency strategic planning and 
cost /schedule/technical commitments, of a mission need 
into an operational system. 
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Figure 1-1 NASA Project Life Cycle 

b. integrated Planning and Management . NASA will approach 
effective program/project planning and management as a 
comprehensive and disciplined process that integrates 
engineering, operational, schedule, procurement, and 
risk factors with Agency affordability and strategic 
planning . 

c. Decision Making and Acco untability. NASA uses a "chain 
of contracts" concept that documents agreements between 
adjacent layers of management throughout all levels of 
management, from the Administrator to the individual 
project managers. These documents are designed to 
clearly identify the authority of their signatories and 
document the commitments for which each is accountable. 
Programmatic direction shall only be issued by the 
accountable persons within the chain of authority 
established for the program. 


1-3 




d. 


Continual Improvement . NASA's programs/projects are 
the most significant and visible way NASA executes its 
responsibilities as an agency. Excellence in the 
Agency's performance depends on excellence in 
program/project management. NASA is committed to 
continual improvement and to the principles of Total 
Quality Management. In order to measure improvement, 
program/project managers are responsible for the 
development of cost, schedule and technical metrics, in 
accordance with the NASA-Wide Metrics Program. 

2. PROCESSES 

a. Life Cycle Phase Transitions . 

(1) NASA has established the transitions from one 
phase to the subsequent phase as key decision- 
making points in the project life cycle. These 
key decisions are based on a system's readiness to 
progress to subsequent phases. This evolutionary 
process is a disciplined way to ensure that NASA 
periodically validates that its projects fulfill 
needs consistent with NASA strategic planning, 
within cost and schedule constraints. Chapter 2 
of this NHB details this process. 

(2) Each phase of a project life cycle includes a 
specific set of objectives and accomplishments 
required to justify a determination of the 
project's readiness to proceed to a subsequent 
phase. The process and decision making authority 
for each phase transition are described in Chapter 
2 . 

b. Review Forums . Independent reviews, including Non- 
Advocate Reviews (NARs) , are performed throughout the 
mission lifetime and constitute the Agency's most 
rigorous independent assessment mechanism. A Program 
Management Council (PMC) , chaired by the Deputy 
Administrator, is the Agency's senior-most review 
forum. The PMC formulates recommendations to the 
Administrator who retains program/project decision 
authority throughout the entire life cycle. This 
process is discussed in detail in Chapter 11. 

c . Project Formulation (Progressive Baseline Definition) . 

During Pre-Phase A, advanced studies explore multiple 
solutions to satisfying a perceived need. These 
studies contribute to a broad, initial understanding of 
the cost/schedule/performance baselines required to 
satisfy the need. The development of these project 
baselines the results from the Project Formulation 
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process of successive refinement, which occurs in 
Phases A and B as illustrated in Figure 1-2. During 
Phase A (Preliminary Analysis) , the mission need is 
defined and initial program/project management systems 
and processes are created to permit structured and 
definitive baselines to be established. Trade studies 
considering affordability, risk, technology content, 
potential procurement strategies, etc. are conducted 
and reflected in cost/schedule/performance baselines. 
During Phase B (Definition), subsequent trade-off 
decisions are made, and these cost, schedule and 
performance baselines are progressively refined. This 
continued refinement process results in a definitive 
cost, schedule and configuration baseline for Phase C 
or C/D. It defines a program/project that satisfies a 
mission need and in which NASA has enough confidence to 
commit to completing within prescribed budgetary and 
schedule constraints. 


Phase A 


Phase B 



Baselines established 

• Requirements 

• Cost 

• Schedule 

• Configuration 


for; 


Decreasing Uncertainly 


Baselines refilled for: 

• Requirements 

• Cost 

• Schedule 

• Configuration 


Figure 1-2 Progressive Project Baseline Refinement Throughout 

Formulation Phases 
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d. Program/Proiect Implementation (Baseline Control) . 

Programs/projects are continually monitored to ensure 
that they are satisfying the performance/cost/schedule 
objectives and constraints reflected in the established 
baselines. Oversight and monitoring approaches are 
designed and implemented to ensure that performance 
against these baselines is objectively assessed and 
anticipated breaches of baseline commitments are 
promptly reported and addressed. Adjustments to any of 
these commitments are made only through formal 
revisions to the commitment documents. 
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CHAPTER 2 


LIFE CYCLE AND PROCESSES 


This chapter provides an overview of the phases of the NASA 
program/project life cycle, the key products; reviews, and 
management processes that control orderly progression through the 
life cycle. The appendices to this chapter establish the 
standards for commitment documents and design reviews as follows: 


APPENDIX 


SUBJECT 


A 

B 


Commitment Document 
Design Reviews 



CHAPTER 2 


LIFE CYCLE AND PROCESSES 


This chapter defines the phases which comprise the NASA 
project life cycle, the key products produced during these 
phases, the major program/project reviews associated with 
these phases and the management processes which control the 
orderly progression throughout the life cycle. 

2 . POLICIES 


Li fe Cycle . Major system projects shall be carried out 
through the five - phase, event driven life cycle process 
depicted in Figure 2-1, which begins with Phase A 
(Preliminary Analysis) and progresses through an 
orderly series of transitions, through Phase E 
(Operations) . Projects shall only proceed from one 
phase to another in the life cycle when all 
prerequisites described in this Handbook have been met. 
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Figure 2-1. NASA Project Life Cycle 


Management Agr eement Structure . The agreements between 
the project manager and senior agency management shall 
be documented and maintained throughout the life cycle. 
These documents, and the respective management 
agreement structure, are identified in Figure 2-2. 

Advanced Studies. Pre-Phase A, Advanced Studies, 
occurs prior to the initiation of the life cycle. 

These advanced studies support the establishment of 
future projects through exploring perceived needs and 
potential solutions to meet them. 

Project Formulation. The first two phases of the life 
cycle, Phases A and B, shall be Headquarters led 
efforts to establish the mission need and provide a 
comprehensive definition of the project. These two 
phases comprise the Formulation portion of the life 






cycle, and must be completed prior to initiating the 
Implementation portion of the life cycle. Proper 
planning during the Formulation period is essential to 
the successful execution of Project Implementation. 
Throughout Phase A and Phase B, parametric cost 
analyses are to be performed in order to assure that 
the Agency has identified the most cost effective 
implementation concept. Concurrently, affordability 
assessments are to be performed to assure that Agency 
financial resources and priorities support such an 
endeavor. In preparing a project for an Agency's 
implementation commitment, realistic cost estimates, 
together with the Agency's ability to meet such a 
financial commitment, shall be of major importance. 
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Figure 2-2. Program/Project Management Agreement Structure 







e. Project Implementation . Implementation is comprised of 
Phase C (Design) , Phase D (Development) and Phase E 
(Operations) . During Project Implementation, the 
detailed design is completed and the system is 
fabricated and tested. Throughout the Phase C and D 
Implementation phases of the project, cost analyses 
shall be performed by the project as well as by 
independent analysts in order to determine adherence to 
cost estimates baselined during the formulation period. 
These dual analyses assure that program costs are being 
contained. Programs which exceed cost thresholds will 
be subject to cancellation reviews. 

f . Reviews . 

(1) Project Reviews 

(a) Figure 2-3 identifies the significant project 
reviews conducted as part of the project 
manager's review and reporting function and 
identifies where the reviews occur in the 
life cycle. These reviews are intended to 
provide the project manager with the 
information necessary to assess progress and 
execute appropriate corrective action, if 
required. Figure 2-3 is not intended to be a 
comprehensive description of all reviews 
conducted on major projects, but rather is 
intended to identify the major reviews 
conducted in support of the project 
management and agency oversight objectives 
covered by this Handbook. 
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2-3. Project Reviews 
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(b) Of the reviews listed in Figure 2-3, the 
Preliminary Design Review (PDR) and the 
Critical Design Review (CDR) shall be 
required of all major programs, shall be 
common in purpose and objective and shall use 
common criteria for adequate completion 
throughout the Agency. The forum for 
achieving the functional objectives of the 
remaining reviews is entirely at the 
discretion of the project manager. 

(c) The functional objectives for the reviews 
indicated in Figure 2-3 are listed below: 

( i ) System Requirements Review ( SRR) . 

Confirms that the requirements and their 
allocations contained in the system/ 
segment specifications are sufficient to 
meet project objectives. Successful 
completion of the SRR freezes program/ 
project requirements. This review leads 
to a formal decision by a PAA to proceed 
with preparations for requesting a 
proposal for Project Implementation. 

(ii) Preliminary Design Review (PDR) . 

Confirms that the proposed project 
baseline is comprehensive (meets all 
program-level requirements) , systematic 
(all subsystem/component allocations are 
optimally distributed across the 
system) , efficient (all components 
relate to a parent requirement), and 
represents acceptable risk. The 
purpose, objective, and completion 
criteria for the PDR are provided in 
Chapter 2, Appendix B. 

( i i i ) Critical Design Review (CDR) . Confirms 
that the project's system, subsystem, 
and component design, derived from the 
preliminary design, is of sufficient 
detail to allow for orderly 
hardware/software manufacturing, 
integration, and testing, and represents 
acceptable risk. Successful completion 
of the CDR freezes the design, and 
concludes Phase C. The purpose, 
objective, and completion criteria for 
the CDR are provided in Chapter 2, 
Appendix B. 

(iv) S ystem Acceptance Review ( SAR) . . 

Demonstrates that the system elements 
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constructed for use will meet all the 
system requirements. This review 
generally leads to formal acceptance of 
the system by the government . 

< v > Elight Read iness Review (frri . Verifies 
the system elements constructed for use, 
and the existing support elements, such 
as the launch site, space vehicle and 
booster, are ready for launch. 

( v i) O perational Readiness Review (ORFd . 

Verifies that the operational support 
elements of the system are ready to 
support system operations. This review 
leads to initiation of Phase E. 

(2 ) Agency Reviews 

(a) Figure 2-4 identifies the reviews required as 
part of the senior agency management approval 
and oversight function and the authority from 
which these reviews flow. These reviews 
assure that : 

(i) Proposed programs/projects are 
consistent with NASA strategic planning, 
adequately defined and within available 
resources; and 

(ii) Are conducted in accordance with the 
commitments contained in Program 
Commitment Agreements (PCA's). 
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Figure 2-4 . Agency Reviews 
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(b) The functional objectives for the reviews 
shown in Figure 2-4 are listed below: 

Agency management with independent 
assessments of the readiness of projects 
to proceed to Phase B or Phase C/D. 

(ii) Program/Project Approval Reviews (PPAR) . 
Enables a Deputy Administrator /PMC 
recommendation for approval to initiate 
a Phase B or Phase C/D effort. 

(iii) Independent Annual Reviews (IAR) . 
Provides an independent verification 
that program/project commitments in the 
PCA are being met. These reviews are 
performed annually. 

(iv) Quarterly Status Reviews ( O SR) . 

Provides quarterly status of 
performance, cost, and schedule against 
baseline . 

( v) L-2 and L-l Mission Reviews (L-2/L-1 
MR) . Provides the Deputy 
Administrator/PMC with an independent 
assessment of progress toward, or 
readiness for, mission operations. 

These reviews are performed at Launch 
minus 2 years and Launch minus 1 year 

(vi) Cancellation Reviews (CR) . Enables a 
Deputy Administ rator/PMC recommendation 
to cancel or continue a major Phase C or 
Phase C/D project. A CR shall be called 
whenever : 

a) The estimate at completion is 
projected, by the PAA or the 
CFO/Comptroller, to exceed the 
baseline Program Cost Commitment 
(PCC) or the Development Cost 
Commitment (DCC) Component of the 
PCC by more than 15 percent, or 

b) Any other PCA threshold requirement 
contained in the PCA is projected 
to be violated. 

(c) Figure 2-5 correlates the timing of project- 
internal reviews with the agency reviews in 
relation to the life cycle. Project reviews 
integrated with Agency oversight reviews 





ensure sufficient content and quality to 
support the Agency decision-making process. 
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Figure 2-5. Project and Agency Reviews 


(d) The relationship between some of the more 

significant project reviews. Agency oversight 
reviews, management agreements, and major 
decisions in relation to the NASA project 
life cycle is illustrated in Figure 2-6. The 
durations shown in Figure 2-6 are 
illustrative. Actual durations should be the 
product of deliberate project planning to 
satisfy the mission need and assure complete 
project definition prior to initiating 
Project Implementation. 

3. PROCESSES 

a . Pre-Phase A - Advanced Studies . 

(1) Objective . Although not a part of the project 
life cycle, advanced studies serve as the first 
step in determining new and potentially promising 
missions deserving of further study. 
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(2) 


Initiation . Advanced studies are authorized at 
the discretion of the Field Installation Director 
(FID) with the acknowledgment of the cognizant PAA 
that the planned study effort is within the 
framework and general scope of NASA strategic 
planning. The FID shall assure that resources are 
focused on studies of the highest priority. 

(3) .Implementation/Products . Advanced studies explore 
a wide range of potential missions or technology 
thrusts. To assure that the studies receive the 
widest possible influx of ideas and approaches, 
NASA encourages broad industry, university, and 
international involvement. Results of the 
advanced studies provide the basis for FIDs to 
determine if further study should be proposed to 
the cognizant PAA as a candidate Phase A effort. 

b . Phase A - Preliminary Analysis . 

(1) Objective . The objective of Phase A, is to 
determine whether a candidate technical objective 
or mission is needed, feasible, and compatible 
with NASA strategic planning. The cognizant PAA 
participates with the FIDs in this evaluation. 

(2) Initiation . Phase A efforts for a candidate Phase 
C/D new start are initiated upon PAA approval of 
an FID recommendation or upon PAA direction to a 
FID. By this approval the PAA has determined that 
sufficient expectation exists for the candidate 
project to proceed to Phase B, and that sufficient 
Pre-Phase A efforts have been expended to assure 
for a successful and timely Phase A effort. The 
cognizant PAA will initiate Phase A by: 

(a) Designating a Headquarters Program Manager or 
Program Director, 

(b) Designating, with the concurrence of the 
cognizant Institutional Associate 
Administrator (IAA), the field 
installation (s) responsible for the 
project (s) definition and implementation, 

(c) Requesting the FID(s) to initiate the Phase A 
effort (s) , and 

(d) Informing Office of Management and Budget 
(OMB) and Congress on the Phase A initiation 
decision and submitting the budget request 
for the first year of Phase B. 
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( 3 ) Implement at ion /Products . 


(a) The primary Phase A products, along with 

supporting information, are provided in Table 
2-1. Figure 2-7 illustrates the Phase A 
activity flow. 


Primary 

Product 

Required By 

Responsible 

Official 

Highest 
Approval 
Level in 
Phase 

Due 

MNS 

Administrator 

Project 

Manager 

Administrator 

Preliminary 

NAR 

Project 

Definition 

Plan 

PAA 

Project 

Manager 

PAA 

Preliminary 

NAR 

Phase B/C/D 
RFP 

PAA 

Project 

Manaqer 

PAA 

Phase A 
Completion 

AO 

PAA 

PAA 

PAA 

Early in 
Phase A 

Preliminary 
NAR Report 

Deputy 

Administrator 

NAR Team 

N/A 

Preliminary 

PPAR 

Preliminary 

IPS 

Deputy 

Administrator 

PAA 

N/A 

Preliminary 

PPAR 

Preliminary 
Program Plan 

PAA 

PAA 

PAA 

Preliminary 

PPAR 


Table 2-1. Primary Phase A Products 

(b) Phase A is based on the efforts expended by 
the NASA field installations during Pre-Phase 
A in-house and contracted advanced studies, 
the knowledge gained from past and on-going 
programs, inputs from activities of various 
advisory structures and private sector 
groups, and the efforts expended by the user 
community. The Phase A effort will be 
conducted primarily by field installation 
staff . 

(c) In certain circumstances, industry may elect 
to fund and complete an equivalent Phase A 
study on their own initiative. The PAA may 
consider these in conjunction with the 
results from other traditional Phase A 
studies in determining those projects worthy 
of further consideration for Phase B. Such 
industry-initiated efforts, if selected, 
shall result in a competitive Phase B/C/D 
acquisition strategy. 
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(d) The Phase A effort includes the definition of 
mission need, development of project-level 
requirements and continuation of advanced 
technology efforts required to support the 
proposed need (including the continued 
assessment of technologies to meet 
requirements, and the continued development 
and maturation of needed technologies) . This 
effort shall also include a determination on 
use of the metric system. 

(e) The following formal management agreements 
must be developed during Phase A: 

(i) Mission Need Statement (MNS) . The MNS 
will be developed, validated with the 
user, and submitted to the PAA for 
approval by the Administrator. The 
mission need is generated as a result of 
a specific deficiency in current agency 
programs or capabilities with respect to 
NASA strategic planning. The MNS shall 
be prepared in accordance with Chapter 
2, Appendix A. 

(ii) Preliminary Program Plan . The 
Preliminary Program Plan defines the 
program-level requirements, management 
organization and responsibilities, and 
the program resources, schedule, and 
controls. This plan shall be prepared 
in accordance with Chapter 2, Appendix 
A . 

(iii) Proiect Definition Plan . This document 
constitutes the plan for implementation 
of Phase B. This plan shall be prepared 
in accordance with Chapter 2, Appendix 
A. 

(f) The following additional products are 
required outputs of Phase A: 

(i) Request for Proposal (RFP ) for Phase 
B/C/D, 

(ii) Announcement of Opportunity (AO) , when 
appropriate, issued in time for the 
initial instrument selection to be 
completed by the time of Phase B 
initiation, 

(iii) Independent Cost Estimate (ICE) , 
produced by the CFO/Comptroller, to 
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provide an independent validation of the 
project's cost estimate, 

(iv) Preliminary NAR Report , produced by an 
independent team, to provide an 
independent validation of the project's 
proposed implementation of the 
requirements, and 

(v) Preliminary Integrated Program/Pro iect 
Summary (IPS) , provided by the PAA, to 
summarize program/project structure, 
status, assessment, plan and 
recommendations. The Preliminary IPS 
shall be prepared in accordance with 
Chapter 11, Appendix 3. 

(g) Both the MNS and the RFP must be supported 
with documentation which describes the 
results and findings of both Pre-Phase A and 
Phase A studies, and provides confirmation 
that the proposed technical implementation 
approaches and periods are the minimum 
necessary to meet the mission need. 

(h) Near the end of Phase A, a Preliminary NAR 
will be conducted to assess readiness to 
proceed to Phase B. As part of the 
Preliminary NAR, an ICE will be generated by 
the CFO/Comptroller. Both the in-house Phase 
A study team results and the results of the 
Preliminary NAR will be presented to the 
cognizant PAA for a decision whether or not 
to request a Preliminary PPAR. 

(i) PAAs will identify and prioritize their 
respective new Phase B candidates based on 
the results of the Phase A studies and in 
consultation with the cognizant FIDs. PAAs 
will then review their candidates with the 
PMC for endorsement. The Council's 
endorsement is to be on the basis of its 
determination that: 

(i) The candidate is compatible with NASA 
strategic planning and the Agency fully 
intends to proceed to the initial phase 
of project implementation (Phase C) at 
the completion of the Phase B effort, 

(ii) All Phase A requirements have been 
satisfactorily met, and 

(iii) The projected implementation resource 
requirements (program and institutional) 
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can be accommodated within expected 
Agency resources . 

c . Phase B - Definition . 

(1) Objective . The objective of Phase B is to 
thoroughly define the program/project requirements 
and to provide sufficient detail definition of the 
project technical, management, budget and 
institutional support plans to enable a firm 
Agency commitment to accomplish the project 
objectives on schedule and within budget. 

(2) Initiation . The Administrator's approval of the 
MNS for a candidate shall constitute approval to 
proceed to Phase B. All candidates approved by 
the Administrator shall be reviewed with the OMB 
and Congressional staffs in a timely manner. 

These reviews should support the Agency budget 
request for the efforts required for the 
candidates beyond the first year of this phase. 

( 3) Implementation/Products . 

(a) The primary Phase B products along with 
supporting information are provided in Table 
2-2. Figure 2-8 illustrates the Phase B 
activity flow. 

(b) The Phase B effort will be conducted in 
accordance with the Project Definition Plan 
and will be based on the MNS, the performance 
requirements contained in the RFP , supporting 
Phase A results and the results of continuing 
technology development and maturation efforts 
to support readiness of required 
technologies. The majority of the effort 
will normally be accomplished by contract, 
although NASA will conduct a parallel in- 
house effort to validate the contracted 
effort and to prepare the field installation 
project management team to perform the 
project technical and management functions 
during Phase C/D. 

(c) A PDR will be conducted near the end of Phase 
B. The requirements, along with the cost 
estimates and project implementation 
schedule, should be in sufficient detail to 
establish a firm technical, schedule and cost 
baseline for the project. This baseline 
provides the basis for finalizing the Project 
Plan prior to start of Phase C/D. 
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Primary 

Product 

Required 

By 

Responsible 

Official 

Highest 
Approval 
Level in 
Phase 

Due 

Reaffirmed 

MNS 

Administrator 

PAA 

Administrator 

End of 
Phase B 

Preliminary 

Project 

Plan 

PAA 

Project 

Manager 

PAA 

NAR 

Preliminary 

PCA 

Deputy 

Administrator 

PAA 

N/A 

NAR 

PCA 

Administrator 

PAA 

Administrator 

PPAR 

BsSSHHHH 

PAA 

Project 

Manager 

N/A 

PPAR 

PDR 

Baseline 

PAA 

Project 

Manager 

N/A 

End of 
Phase B 

Contractor 

Selection 

Decision 

Project 

Manager 

Source 

Evaluation 

Board 

Source 

Selection 

Official 

Prior to 
Phase B 
Completion 

Instrument 

Selection 

Decision 

PAA 

"PAA 

PAA 

Early 
Phase B 

NAR Report 

Deputy 

Administrator 

NAR Team 

N/A 

PPAR 

Project 

Plan 

PAA 

Project 

Manager 

PAA 

End of 
Phase B 

PCA 

Administrator 

PAA 

Administrator 

Annually 

IAR Report 

Administrator 


NAR 

Annually 

IPS 

Deputy 

Administrator 

PAA 

N/A 

PPAR 

Final 

Program 

Plan 

PAA 

PAA 

PAA 

PPAR 


Table 2-2. Primary Phase B Products 


(d) A set of multiple descope proposals generated 
by the project office shall be included in 
the baseline. These descope options shall 
include both reduced mission scopes, along 
with their respective reduced systems 
requirements, which correspond to a mission 
and system constrained by reduced resources. 
The descope plans shall be systematic, 
identifying reduced systems capability 
against reduced mission objectives, and shall 
identify a threshold below which no efficient 
mission would be possible. This threshold 
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defines a system's minimum acceptable 
functional and performance characteristics 
necessary to satisfy the mission objective. 

(e) If changes are necessary to the established 
PDR baseline, a formal configuration control 
procedure must be utilized. 

(f) The following formal management agreements 
must be developed or updated during Phase B: 

(i) Mission Need Statement (MNS ) will be 
reaffirmed, 

(ii) Project Plan for implementation of Phase 
C/D prepared in accordance with Chapter 
2, Appendix A. A Preliminary Project 
Plan will be developed early in Phase B, 
and then finalized at the conclusion of 
Phase B, 

(iii) Program Commitment Agreement (PCA) f 
prepared in accordance with Chapter 2, 
Appendix A. A Preliminary PCA shall be 
prepared to be available at the PPAR. 
Preparation of the PCA will be 
coordinated with the CFO/Comptroller 
prior to submittal. 

(g) The following additional products are 
required outputs of Phase B: 

(i) SRR System Specification , which includes 
a formal flow down of the project-level 
performance requirements (as documented 
in the RFP) to a complete set of system 
and subsystem design specifications. 

The system requirements shall be frozen 
at SRR. 

(ii) PDR Baseline , which includes the 
corresponding preliminary designs 
(developed in accordance with the Class 
1 or Class 2 competition) , 

(iii) Contractor Selection Decision (see 
Chapter 4, Acquisition Management), 

(iv) In strument Selection Decision (if 
applicable) , and 

(v) NAR Report including an ICE produced by 
the CFO/Comptroller to provide an 
independent validation of the project's 
cost estimate. 
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(h) Upon Agency receipt of Limited Authority to 
Proceed (ATP) from Congress, the 
program/project will proceed with development 
of products sufficient to conduct a NAR 
(including an ICE) and a PPAR. Successful 
completion of these milestones is a 
prerequisite for the Agency to request Full 
ATP. These reviews assure that: 

(i) All Phase B requirements have been 
satisfactorily met, and 

(ii) The implementation resource requirements 
proposed for OMB submittal are valid and 
within the expected agency resources. 

(i) The PPAR is in the form of a Phase C/D start 
decision presentation to the PMC. This 
presentation will include the results of the 
NAR and the SRR and be accompanied by the 
Preliminary PCA and the Preliminary Project 
Plan . 

(j) Following PMC endorsement, the 
Administrator's approval will be obtained 
through approval of the Preliminary PCA. The 
PCC contained in this approval will be 
submitted to OMB in the Agency budget request 
thus seeking Administration approval of the 
new Phase C/D start. After submission to the 
OMB, all program-level requirements and the 
PCA will be frozen and placed under 
configuration control. 

(k) The final year of Phase B comprises the 
period between submittal of the new Phase C/D 
start approval request to OMB (usually by 
September 1 of the year before the fiscal 
year being budgeted) and Congressional 
approval of the budget (usually the late 
summer/fall before the budget year) . This 
period will be used to complete: 

(i) Comprehensive definition of the 
technical and management content of the 
project, preliminary design and 
finalization of all project and lower 
level plans, and 

(ii) Final down-selection to a single 
contractor (if not previously 
accomplished) 

(l) Upon receipt of Congressional approval of the 
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budget, the PAA will determine the impact on 
the Preliminary PCA of any change in the 
budget from that submitted and of any 
accompanying Congressional direction that 
changes program content or implementation 
plans. These impacts and corresponding 
revisions to the Preliminary PCA and other 
elements of the program will be prepared and 
presented to the Deputy Administrator /PMC . 

The PMC will then develop a recommendation to 
the Administrator as to whether to proceed 
with a revised program/project compatible 
with the approved budget or to proceed with 
cancellation. The Preliminary PCA and other 
elements of the program/project will be 
updated as necessary to reflect the 
Administrator's decision. The 
Administrator's signature on the revised PCA 
concludes Phase B and establishes the PCA 
that governs Phases C/D/E. 

d . Phase C - Design . 

(1) Objective . The objective of Phase C is to 
complete the detailed design. 

(2) Initiation . Approval to initiate Phase C (or 
Phase C/D) shall be obtained through Administrator 
approval of the PCA and PAA approval of the final 
Project Plan. These approvals are prerequisites 
to the release of Phase C/D funding. 

(3) Implementation/Products . 

(a) The primary Phase C products along with 
supporting information, are provided in Table 
2-3. Figure 2-9 illustrates the Phase C 
activity flow. 

(b) Phase C consists of detailed system design 
with mock-ups and test articles of critical 
systems and subsystems. Phase C is normally 
combined with Phase D, but shall be performed 
separately if a large production quantity is 
planned. During Phase C, the 

project/ contractor team will maintain systems 
development within the established 
performance, schedule and cost parameters. 

(c) Throughout the Phase C period, the baseline 
preliminary design is evolved to the 
completion of the detailed baseline design at 
the CDR level. The user or user's 
representative continues to interact with the 
project office to participate in the trade- 
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offs necessary to refine system and product 
specifications and to assure that test 
procedures properly verify performance 
requirements. The CDR milestone will include 
a comprehensive validation process necessary 
to assure that all derived requirements and 
specifications properly represent the program 
and project requirements. The completion of 
the CDR marks the conclusion of Phase C. 


Primary 

Product 

Required 

By 

Responsible 

Official 

Highest 
Approval 
Level in 
Phase 

Due 

Validated 

PCA 

Administ rat or 

PAA 

Administrator 

Annually 

CDR Specs/ 
Baseline 

PAA 

Project 

Manaqer 

N/A 

End of 
Phase C 

P SR 

Congress 

PAA 

Administrator 

Semi- 

annually 

CMR 

Administrator 

Project 

Manager 

PAA 

Quarterly 

QSR 

Deputy 

Administrator 

Project 

Manger 

PAA 

Quarterly 

IAR Report 

Admin i st rat or 

' CFO/ 

Comptroller 

N/A 

Annually 


Table 2-3. Primary Phase C Products 


(d) All the management agreements in effect at 
the conclusion of Phase B are the operative 
documents for the implementation of Phase C. 
These documents shall be maintained 
throughout Phase C. This shall include an 
annual revalidation of the PCA. 

(e) The following additional products are 
required outputs of Phase C: 

(i) CDR Baseline , including: 

a) Detailed CDR-level system and 
component specifications, 

b) A CDR-level Systems Baseline 
Description describing the 
resultant systems level design, and 

c) CDR-level requirements traceability 
establishing the linkage of all 
derived requirements to parent 
requirements and assuring that no 
orphan requirements exist . 






Administrator 
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Figure 2-9. Phase C Activity Flow 











(ii) Project Status Reports (PSR'.aL, 


(iii) Contractor Metrics Reports (CMR's), if 
required, and 

(iv) Quarterly Status Reports (QSR' S) . 

e . Phase D - Development . 

(1) Objective . The objective of Phase D is to develop 
the system hardware and software and provide an 
operational system that satisifies the PCA and is 
accepted by the ultimate user. 

(2) Tni ti at ion . For those programs/projects which 
include full scale production of multiple units 
and require implementation of Phase D as a 
discrete phase. Phase D efforts shall not be 
initiated until the Administrator has reaffirmed 
the mission need and system performance has been 
adequately tested and evaluated. Approval 
prerequisites consist of a revalidation of the MNS 
and PCA, and the endorsement of the PMC. The 
Administrator's approval shall be formally 
documented . 

(3) Implementation/Products . 

(a) The primary Phase D products along with 
supporting information, are provided in Table 
2 - 4 . Figure 2-10 illustrates the Phase D 
activity flow. All the management agreements 
in effect at the conclusion of Phase C are 
the operative documents for the 
implementation of Phase D. These documents 
shall be maintained throughout Phase D. This 
shall include an annual revalidation of the 
PCA. Throughout the conduct of Phase D, all 
reports will continue as in Phase C. 

(b) Phase D comprises the fabrication, 
integration, certification and testing of all 
system hardware/software required to provide 
for Phase E initiation and recurring 
operations. Throughout system development, 
testing procedures or, as appropriate, 
engineering analysis will be employed at 
every level of systems synthesis in order to 
assure that the fabricated system components 
meet their requirements. This will include 
verification that the end-to-end system meets 
the total system requirements. 
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Primary 

Product 

Required 

By 

Responsible 

Official 

Highest 
Approval 
Level in 
Phase 

Due 

PCA Validated 

Administrator 

PAA 

Administrator 

BSEBSm 

Multiple Unit 

Production 

Authorization 

Administrator 

N/A 

Administrator 

Per Phase 
C/D/E 
Program 
Plan 

PSR 

Congress 

PAA 

Administrator 


CMR 

Administrator 

Project 

Manager 

PAA 

Quarterly 

QSR 

Deputy 

Administrator 

Project 

Manger 

PAA 

Quarterly 

IAR Report 

Administrator 

CFO / 

Comptroller 

N/A 

Annually 

L-2/L-1 MR 
Reports 

: Administrator 

PAA- 

appointed 

Team 

N/A 

Launch - 
2 yrs/1 
yr . 

Operational 

System 

PAA 

Project 

Manager 

N/A 

End of 
Phase D 


Table 2-4. Primary Phase D Implementation Products 

(c) Initial flight test activities shall include 
deployments, engineering evaluations, and 
operational acceptance characterizations. 

The characterization testing is intended to 
ascertain the performance of the overall 
system in its operational environment. For 
this purpose, the total end-to-end system 
(institutional and mission unique) will be 
exercised as it relates to meeting all 
project-level requirements. The metrics 
derived from these tests may be used to 
establish award fee to the mission 
contractor . 

(d) During Phase D, the PMC shall review the PCA 
annual validation and may request such 
additional reviews as required to ensure 
conformance to the PCA. In addition, the 
Phase D effort shall include two MR's 
conducted at approximately two (L-2) and one 
(L-l) years before launch or the equivalent 
system delivery date. These reviews are to 
be conducted by an independent group of 
experts in order to assess and determine 
operational readiness of the system to safely 
conduct the mission and to meet the user 
performance requirements. 
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Figure 2-10. Phase D Activity Flow 










Phase E - Operations . 


f . 


(1) Objective . The objective of Phase E is to satisfy 
the mission need. 

(2) Initiation . Phase E commences with delivery of 
the system to the ultimate operator/user for use 
in its intended environment. 

(3) Implementation/Products . Figure 2-11 illustrates 
the Phase E activity flow. These activities 
include : 

(a) Routine operations of the ground and flight 
systems necessary to conduct the mission, 
including, but not limited to, the following 
activities : 

(i) Logistics support as required for the 
life of the system in accordance with 
NMI 7500, "Acquisition Logistic Policy", 

(ii) Sustaining engineering, and 

(iii) Any additional hardware or software 
development required by the Project 
Plan . 

(b) At the discretion of the PMC, the project may 
be reviewed quarterly throughout the life of 
the mission, for such activities as useful 
service lifetime, user service availability, 
and/or reliability as they compare to the 
respective requirements, or other performance 
metrics to document "lessons learned". 





Phase E Go-Ahead Decision 



Figure 2-11. Phase E Activity Flow 










CHAPTER 2 


APPENDIX A: COMMITMENT DOCUMENTS 


This Appendix establishes the format and content for the 
following basic commitment documents associated with major 
programs/projects: 


MISSION NEED STATEMENT 
PROGRAM COMMITMENT AGREEMENT 
PROGRAM PLAN 
PROJECT PLAN 

All documents shall be prepared on NASA letterhead in accordance 
with these prescribed formats. In addition, it is also required 
that the PCA not exceed 3-4 pages in length. 
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Major System Acquisition Mission Need Statement 


(Provide a title for the candidate program and designate a short 
title or proposed acronym in parenthesis if appropriate.) 


Agreements : 


Program Associate Administrator Date 


Administrator Date 


Title Page 


2-A-2 



MISSION NEED STATEMENT 


(PROGRAM TITLE) 


1. MISSION PURPOSE . 

Identify the mission purpose and state the need to be filled 
in terms of NASA strategic planning and the mission 
(program/ project) to be accomplished. The mission need is 
independent of any particular system or technological 
solution and shall be stated in terms of functional 
capabilities . 

2. VALUE OR WORTH OF MEETING NEED . 

Assess the scientific or technical value or worth of meeting 
the need and any additional benefits to be derived. 

3. RELATIVE PRIORITY . 

Indicate the priority of commencing the mission in relation 
to the time the mission opportunity presents itself. 

4. CAPABILITY ASSESSMENT . 

Assess the need in terms of an existing science, technology, 
or applications deficiency, projected physical obsolescence, 
cost saving opportunity, or environmental impact. Identify 
any existing capability to accomplish the mission. 

5. CONCEPT/APPROACH . 

Indicate, including supporting rationale, if this is 
considered to be a Class 1 or 2 mission need concept. (A 
Class 1 is the determination that the potential exists for 
an alternative system design concept procurement, and Class 
2 is the determination that only a single system design 
concept is to be pursued.) 

6. SYSTEM ELEMENTS / COMPONENTS . 

Identify all elements/components that make up the major 
system acquisition. 

7 . FUNDING . 

Identify, by fiscal year, the funding that the agency would 
be required to commit for Phases B, C/D, (i.e., the DCC 
component of the PCC) and E. For programs planned to be 
operated for many years, the operations cost shall be 
expressed in terms of anticipated annual operating expense. 
Indicate confidence in the validity of the availability of 
such funding. 
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Resources 

(NOA) 

FY1 

FY2 

FY3 

FY4 

FY5 

• • • 

FYn 

TOTAL 










Phase B 









Phase C & 
D 









Phase E 









Total 








i 


8 . PRIOR STUDIES DOCUMENTATION . 

Briefly summarize the results of prior studies that were 
performed which support this major system acquisition. 
Identify by reference the study documentation. 

9. AGENCY COMPONENTS INVOLVED . 

Identify the Agency components (program office, project 
office, etc.) to be involved in the mission and their roles 
and responsibilities. 

10 . TIME CONSTRAINTS . 

Indicate the time constraints impacting the accomplishment 
or start of the program requirement. 

11 . OPERATING CONSTRAINT . 

Outline the operating constraints that would impact the 
successful implementation of the mission (capabilities, 
facilities, outside agreements, commitments, etc.) 




Program Commitment Agreement 


[Provide a title for the candidate program and designate a 
short title or proposed acronym in parenthesis if 
appropriate . ] 


It is the responsibility of each of the signing parties to 
notify the other in the event that a commitment cannot be 
met, and to initiate the timely renegotiation of the terms of 
this agreement . 


Program Associate Administrator 


Date 


Administrator 


Date 


Title Page 
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PROGRAM COMMITMENT AGREEMENT 


(PROGRAM TITLE) 


1 - PROGRAM OBJECTIVES . 

This paragraph should convey the following: 

- The broad program objectives in plain English. 

- The public good of the program to the taxpayer stated in a 
way that can be understood by the average taxpaying 
citizen. 

2 . PROGRAM OVERVIEW . 

This paragraph should provide a broad description of the 
strategy to achieve the above mentioned objectives while 
retaining the flexibility of the PAA in implementing the 
program. 

3. T ECHNICAL AND SCHEDULE COMMITMENTS . 

This section should provide: 

(1) A high-level description of the technical capability 
resulting from the activity, e.g., an expendable launch 
vehicle capable of delivering 20,000 lbs. to a 300 
nautical mile circular orbit at 28.5 degrees 
inclination. The threshold requirements for the 
technical capability, i.e., the requirements which, if 
not met, would result in the basic mission objective 
not being satisfied, shall also be defined. 

(2) Key milestones, e.g. 

(a) Launch date of each spacecraft, launch date for a 
vehicle first flight, first element launch; 

(b) Minimum period of operation of each spacecraft; 

(c) Date on which validated science results will be 
archived for use by the general science community 
or when user services would be made available to 
the user community. 

4 . RESOURCE COMMITMENTS . 

This section contains the PCC and its component elements 
presented in the format shown in Figure 2-A-l . These 
commitments shall be specified in accordance with the 
definitions of Figure 2-A-l and Appendix A of this 
instruction and with the following: 
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(1) All resources through the end of nominal mission 
lifetime shall be included, i.e., through prime 
mission . 

(2) The Construction of Facilities (C of F) resources shall 
include all resources required to construct, modify or 
outfit facilities to satisfy the system technical and 
schedule commitments. 

(3) The launch vehicle related resources shall include the 
launch vehicle, launch site, and any project unique 
launch vehicle related resources necessary to satisfy 
the system technical and schedule commitments. 

(4) The tracking and data resources shall include all 
project-unique tracking and data acquisition 
capabilities and services necessary to satisfy the 
system technical and schedule commitments 

5 . PROGRAMMATIC RTSK . 

This paragraph should identify areas of exceptional risk 
(technical, programmatic, supportability, cost, and 
schedule) where failure in one or more of those areas might 
expose the Agency to adverse social or political 
consequences and/or result in an extreme negative 
programmatic impact (examples of risk areas might be 
planetary launch windows, launch of nuclear power sources, 
etc.) . This section should also identify the actions taken 
to mitigate the risks. 

6 . INTERNAL NASA AGREEMENTS . 

This paragraph should contain a brief overview of the NASA 
internal agreements necessary to meet the commitments, and 
should reference those agreements which provide the details 
of the required support. Consideration should be given to 
all support commitments/ as, for example: 

1 . C of F 

2. Provision of launch vehicle and launch site 

3. Tracking and data acquisition 

4 . Any other technical or institutional support 

There shall be a one for one correlation of the items 
referenced above with the items identified in Section 4. 

Project plans with NASA field installations including civil 
service workforce level commitments should be included 
(concurrence of the IAA is required if outside the 
implementing PAA authority) . Supporting field installation 
workforce levels are to be identified in the Program Plan. 
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7. 


EXTERNAL AGREEMENTS . 


This paragraph should list all the inter-agency and 
international agreements necessary to meet the commitments. 

8. PCA ACTIVITIES LOG . 

This section shall contain a log of all activities 
associated with maintenance of the PCA including the annual 
revalidations and all deviations to the original PCA. This 
log shall be in the format shown below, and shall be 
supplemented with an addendum for each change, which 
describes the change, and is attached to the PCA. 

PCA ACTIVITIES LOG (SAMPLE) 


Date 

Event 

Change 

Addendum 



Administrator 

Signature 








dd/mm/94 

Annual 

Revalidation 

None 

N/A 

NO 



dd/mm/95 

Annual 

Revalidation 

None 

N/A 

NO 



dd/mm/96 

POP 96 

reduced FY97 
by $ 15M 

Deleted 

Real-time 

Data 

Products 
to Users 

Ref. #1 

No 
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Program Plan 


[Provide a title for the candidate program and designate a 
short title or proposed acronym in parenthesis if 
appropriate.] 


Program Associate Administrator 


Program Director (If Applicable) 


Field Installation Director or 
HFI Program Manager 
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PRELIMINARY PROGRAM PLAN 
OR 

PROGRAM PLAN 

PROGRAM PLAN 
(PROGRAM TITLE) 


1. INTRODUCTION . 

Briefly state the background of the program and its current 
status, including the results of Pre-Phase A and Phase A 
activities, decisions, and documentation such as the MNS. 

State that the main purposes of this Program Plan are to 
establish: 

(1) Program objectives, 

(2) Program-level requirements, 

(3) The management organizations responsible for the 
program throughout its life cycle. 

(4) Program-level resources, schedules, and controls. 

Briefly summarize the scope of the information covered in 
the remaining sections. 

2. PROGRAM OBJECTIVES . 

State program objectives and their relationship to NASA 
program goals as set forth in NASA strategic planning. 

3. PROGRAM-LEVEL REQUIREMENTS . 

Define the program-level requirements. For multiple 
projects within a program, describe the way in which program 
level requirements will be allocated to the respective 
projects . 

4 . PROGRAM ELEMENTS AND ORGANIZATIONAL RESPONSIBILITIES . 

Briefly describe the major components of the program and how 
they will be integrated together; including how the program 
will relate to other institutions within NASA as well as 
outside of NASA. Identify the responsibilities of each 
field installation as they relate to their respective 
requirement allocations referenced in paragraph 2 above. 
Describe the overall architecture of the program. 

a . Organization . 

Describe the NASA organizational structure for managing 
the system program and projects from the PAA to the 
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field installation project managers. Include lines of 
authority, coordination, and reporting; illustrate the 
organization graphically, using as guidance NMI 
7120. 4 A . 

b. Responsibilities . 

Define management responsibilities of the PAA, IAA(s), 
SAA(s), the Program Director (if applicable), the 
Program Manager, and Project Manager (s), including the 
authority of these persons as described in NMI 7120.4. 
Indicate their responsibilities for developing, 
concurring, and approving principal program documents, 
such as the MNS, project-level requirements, the 
Program Plan, Project Plans, RFPs and other contract- 
related documents, reports associated with major 
reviews and other key activities. 

5. PROGRAM RESOURCES . 

Identify for each participating field installation yearly 
New Obligation Authority (NOA) estimates for system 
development and operations, facility construction, 
institutional support, and management. Civil service 
workforce levels should be included. 

6. SCHEDULE . 

Provide a schedule of program-level activities and events 
covering the system life cycle from Phase B through Phase E; 
include all applicable events, such as approval dates for 
entry into phases, approval dates for major program and 
projects documents, instrument selection dates, dates of 
major project reviews, launch date(s) (or equivalent system 
"delivery" date (s) ) , launch minus one-year and two-year (L-l 
and L-2) MR's, and other Administrator or PAA decisions. 
Identify all headquarters-controlled milestones 

7 . CONTROLS . 

Describe the process by which project-level requirements are 
validated for compliance with the program-level 
requirements. Describe the process for controlling changes. 

Describe the process for updating the PCA as a result of any 
changes. Indicate key program parameters (cost, schedule, 
and technical) which will require Administrator, PAA, or HFI 
Program Manager approval for change. 

Identify the Allowance for Program Adjustment (APA) and 
reserves management strategy and approval authority. 
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Project Plan 


[Provide a title for the candidate program and 
short title or proposed acronym in parenthesis 
appropriate . ] 

designate a 
if 

Aareements : 




Program Associate Administrator 

Date 

Program Director/HFI Program Manager or 
Field Installation Director 

Date 

Project Manager 

Date 


Title Page 
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PROJECT DEFINITION PLAN 
or 

PROJECT PLAN 
or 

PRELIMINARY /PROJECT PLAN 
[TITLE] 


FOREWORD 

1 . INTRODUCTION . 

1.1 Identification 

1.2 Background 

1 . 3 Summary 

The project is identified by an officially approved title, 
NASA Program, PCA, and/or Unique Project Number (UPN) . A 
brief general history of the project is given. A brief 
summary is given, including the project's purpose, overall 
approach and timeframe. For multiple field installation 
projects, describe the field installation's project in 
relationship to the other participating field installations. 

2. OBJECTIVES . 

State the specific project objectives and their relationship 
to the program objectives. 

3. MANAGEMENT . 

3.1 Organization and Responsibilities 

3.2 Special Boards and Committees 

3.3 Management Support Systems 

Describe the project management structure including its 
integration into the program management structure, field 
installation participation. Identify all significant 
interfaces with other contributing organizations. Be 
consistent with the roles and responsibilities prescribed in 
NMI 7120.4. Identify specific management tools to support 
management in planning and controlling the project. 

Describe the use of special boards and committees. 

4 . RELATIONSHIP TO OTHER PROGRAMS . 

4.1 Related Activities and Studies 

4.2 Related Non-NASA Activities and Studies 

4.3 Internal NASA Agreements 

4.4 External Agreements 
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Other NASA, U.S. agencies and international activities, 
studies and agreements are summarized with emphasis on their 
effect on the program. 

5. TECHNICAL SUMMARY . 

5.1 Project-level Requirements 

5.2 System(s) 

5.3 System Operations Concept 

5.4 System Constraints 

5.5 Ground Systems and Support 

5 . 6 Facilities 

5.7 Logistics 

5.8 Mission Results Analysis and Reporting 

Project level requirements are presented along with a 
technical description of the project. This includes the 
allocation of these requirements among the systems to be 
developed (hardware and software) , use of the metric system, 
facilities, flight plans, operations and logisitcs concepts, 
and planned mission results analysis and reporting. 

6. TASK DESCRIPTIONS . 

6.1 Implementation Approach 

6.2 Project Summary Work Breakdown Structure 

The implementation mode of the project is described (e.g., 
in-house, field installation prime, contractor prime) . A 
project-level work breakdown structure (WBS) shall be 
provided . 

7 . PROCUREMENT SUMMARY 

Provide summary information on procurement items, such as: 
element (engineering design study, hardware development, 
mission and data operations support, etc.); type of 
procurement (competitive, Announcement of Opportunity for 
instruments, etc.); type of contract (cost reimbursable, 
fixed price, etc.); source (institutional, contractor, other 
government organizations, etc.); procuring activity (NASA 
installation) ; and technical monitoring (NASA installation) . 

8 . SCHEDULES . 

Present the project master schedule for all major events and 
activities planned for the entire project throughout all 
remaining phases of the program. Include approval dates for 
principal program/project documentation, life cycle 
transitions, major reviews, Headquarters controlled 
milestones, and significant contract milestones. Identify 
lower level schedules to be developed and maintained. 
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9. 


RESOURCES . 


9 . 1 Funding Requirements 

Present a funding requirements chart that includes the 
same elements as for the procurement summary (see 
Section 7) . Show the NOA in real year dollars for the 
prior, current and remaining fiscal years. The level 
of detail should be at WBS 2.0 level or its equivalent. 

9.2 Institutional Requirements 

Present the institutional requirements for the entire 
project throughout its life cycle. Include Civil 
Service workforce requirements on the providing 
organizations for the prior (actuals) , current, and 
remaining years. 

10 . MANAGEMENT REVIEWS . 

10.1 Program-Level Reviews 

10.2 Project-Level Reviews 

Provide the names, purposes, content and timing of all 
reviews shown in the Schedules section. Explain the 
reporting requirements for each. 

11. CONTROLS 

11.1 Administrator 

11.2 Program Associate Administrator 

All technical performance, cost, or schedule parameters 
specified as requiring approval to change by the 
Administrator, the PAA or HFI Program Manager (if 
applicable) should be identified. (Examples include funding 
by year, program-level requirements, project objectives, 
program and project management structure, and major 
program/project documentation.) Identify the thresholds 
associated which each parameter which could cause a CR. 

Describe the process by which project-level requirements are 
validated for compliance with program-level requirements. 
Describe the process for controlling changes to these 
requirements . 

12. PERFORMANCE ASSURANCE *. 

12.1 General 

12.2 Reliability 

12.3 Quality Assurance 

12.4 Parts 

12.5 Materials and Processes Control 

12.6 Performance Verification 

12.7 Contamination Allowance and Control 
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12.8 Software Assurance 

12.9 Maintainability 

For each of the subsections, cite the relevant requirements 
documents and summarize how they will be followed. The 
plans and specific procedures should be identified to 
accomplish the applicable performance assurance items listed 
in the subsections. 

13. RISK ASSESSMENT *. 

All major programmatic and technical risks should be 
identified along with the planned approach to reduce the 
risks to acceptable levels. Refer to Chapter 6 of this 
Instruction for guidance on risk management planning. 

14. ENVIRONMENTAL IMPACT * . 

The required environmental impact assessment /statements for 
the project should be identified along with the schedule for 
their accomplishment 

15. SAFETY *. 

13.1 Industrial Safety 

13.2 Range Safety 

13.3 System Safety 

For each of the subsections, cite the relevant safety 
requirements documents and summarize how they will be 
followed . 

16. SECURITY *. 

Cite the relevant institutional and NASA security 
requirements documents and summarize how they will be 
followed . 


* Project Definition Plan requires only a description of 
the general approach. 
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CHAPTER 2 


APPENDIX B: DESIGN REVIEWS 

PRELIMINARY DESIGN REVIE W 


1 . 


The PDR is held at the system, subsystem and component level 
to demonstrate preliminary designs meet system requirements 
with acceptable risk. All interfaces and verification 
methodologies must be identified. 

Successful completion of the PDR will result in approval of 
configuration item specifications, release of the 
preliminary design drawings, and serve as prerequisite to 
proceeding with detailed design. 

2 . OBJECTIVES . 

The objectives of the PDR are to assure that: 

(a) All system requirements have been allocated to the 
subsystem and component level and the flow down is 
adequate to verify system performance. 

(b) The design solution being proposed is expected to meet 
the performance and functional requirements at the 
configuration item level. 

(c) There is enough evidence in the proposed design 
approach to proceed further with the next step of 
detailed design phase. 

(d) The design is verifiable and does not pose major 
problems which may cause schedule delays and cost 
overruns . 

3. CRITERIA FOR SUCCESSFUL COMPLETION . 

(a) There is evidence that the preliminary design will meet 
performance, cost, and schedule as planned. 

(b) Overall system architecture has been established and 
all the external interfaces have been identified. 

(c) All system, subsystem and component specifications are 
complete and ready for formal approval. 

(d) The proposed design does not violate any safety 
requirements which will endanger human life or mission 
success . 
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(e) The reliability analysis is based on a sound 
methodology and presents realistic predictions for 
logistics planning and life-cycle cost analysis. 

(f) The design solution is producible based on existing 
processes and techniques; if not, risk areas which 
require unique and unproven processes are identified 
and plans established. 

(g) There are no or minimum number of long lead items which 
may threaten schedule compliance. 

(h) Required resources (workforce and facilities) are 
available to proceed further. 

(i) An acceptable operations concept has been developed. 
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CHAPTER 2 


APPENDIX B: DESIGN REVIEWS 

CRITICAL DESIGN REVIEW 


1 . PURPOSE . 

The CDR is held after completion of design development 
activities i.e., completion of detailed design phase. All 
technical problems and design anomalies must be resolved 
without compromising system performance, reliability and 
safety . 

Successful completion of the CDR will result in the release 
of approved drawings for fabrication, approval of 
manufacturing plan, test plan and procedures, and permission 
to proceed with the software coding and system qualification 
testing and integration. 

2. OBJECTIVES . 

The objectives of the CDR are to assure that: 

(a) The detailed design will meet performance and 
functional requirements. 

(b) All recommendations from design audits by specialty 
engineering groups, manufacturing, safety, quality, 
operations and utilization and test organizations have 
been answered and all action items are closed. 

(c) The design can be smoothly transitioned into the 
manufacturing phase. 

(d) The program is ready to commit to setting up tooling, 
facilities and manpower to fabricate, integrate and 
test based on this design baseline. 

3. CRITERIA FOR SUCCESSFUL COMPLETION . 

(a) There is substantial evidence that the detailed design 
will meet performance, cost and schedule as planned. 

(b) Fabrication drawings have been completed with a 
complete inventory of bill of materials including any 
long lead items. 

(c) Software simulations and prototyping results do not 
present any potential risks which may hamper software 
coding and integration. 
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(d) All engineering analyses such as thermal, power 
distribution, and stability are complete, accurate and 
the detailed design is based on these results. 

(e) Integrated safety analysis shows that there are no 
outstanding hazards which cannot be controlled or are 
within an acceptable risk level if waivers are 
required . 

(f) The integrated logistics analysis shows complete spares 
provisioning for the life of a program. 

(g) A comprehensive system verification approach (that 
minimizes on-orbit checkout risks for flight systems) 
has been established. 
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CHAPTER 3 


KEY PERSONN EL 


1 - PURPOSE 

An important factor in determining a program/pro jects 1 
readiness to move from one phase to the next phase will be 
the qualifications of the key personnel. These policies 
and procedures specify the human resources policies and 
procedures that must be followed to ensure that NASA has 
highly qualified people in all key PPM positions. 

2. POLICIES 

a - Key Perso nnel Selection . Key PPM personnel will meet 

the qualification criteria for assignment to a program 
or project. The decision criteria on the selection of 
key personnel will encompass previous assignments and 
their accomplishments in getting the program 
objectives accomplished within budget and on schedule. 
Other criteria that will be evaluated is training, 
education and development opportunities they have 
experienced . 

b. Kev Personnel Qualifications . The qualifications of 
key PPM personnel shall include: 

(1) Demonstrated technical expertise, including 
hardware and software development experience, is 
mandatory . 

(2) System integration skills which include 
engineering and analysis, testing, and systems 
interface management. A working knowledge of the 
project life cycle, work breakdown structure, 
risk management, control gates, and system 
analysis and modeling. 

(3) Planning skills which include a working knowledge 
of project planning tools and their use in 
project implementation and strategic planning 
including the establishment of contingencies for 
time, funding and other resources. 

(4) Business management skills such as competence in 
program control and specific knowledge of program 
planning and scheduling, cost estimating, 
budgeting and performance measurement. An 
understanding of institutional requirements and 
the system acquisition approach (e.g. contract 
management, procurement, source evaluation 
boards) . 
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(5) Human resource management skills in one-on— one 
and group settings. This includes the ability to 
develop employees, performance management, 
delegation skills, managing conflict, 
establishing collaborative and open work 
environments . 

(6) Communication skills including both written and 
oral skills. This includes the ability to 
prepare clear, precise documents (e.g. statements 
of work, plans, specifications) and the ability 
to provide timely feedback to individuals (both 
positive and critical) . The ability to 
communicate openly and honestly the overall 
goals, roles, and current events of a project is 
a key requirement . 

(7) Teamwork skills including the ability to work 
across organizational lines effectively and 
cooperatively. (The team includes members of 
centers, headquarters, top management, peers, 
procurement, contractors, and members of external 
organizations . ) 

c. Training and Development . The agency will implement a 
systematic training and development program as 
required for supplying the agency with an adequate 
number of well qualified candidates to fill project 
management positions. Training and development 
programs will be structured around proven 
characteristics of effective program and project 
managers based upon NASA research and other studies 
and shall be consistent with the following guidelines: 

(1) New members of the project workforce shall be 
provided with an understanding of what it takes 
to progress to the next step in their careers. 
Individual Development Plans (IDPs) will be used 
to focus individual efforts and communicate 
anticipated individual developmental 
requirements . 

(2) Agency management will require a continuum of 
development activities for project managers from 
new hire to senior executive level. Work 
experience, developmental assignments, and a 
training curriculum will be provided to enable 
the continuous improvement of project managers. 

(3) While formal education is not a requirement for 
project management success, an advanced degree 
will be encouraged by senior managers. 
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(4) Developmental assignments, and rotations to other 
organizations, will be encouraged. Rotational 
assignments should include the technical needs of 
the individual as well as exposure to business 
management principles. 

d. Executive Responsibilities . The PMC will provide the 

overall direction for the establishment and maintenance 
of the program/project manager qualifications and for 
the corresponding NASA development program to assure 
NASA personnel meet these qualifications. The 
Program/Project Management Steering Group (PPMSG) will 
support the PMC in this function by providing oversight 
of the PPM Training and Development Program. 

3. PROCESSES 

a. Development Processes . Headquarters and field 
installations will establish processes that assure 
personnel have the opportunity to move through a 
progressively increasing set of responsibilities for 
achieving project objectives, within budget and on 
schedule, and attend training and development 
opportunities that deal with the full spectrum of 
program management activities. Program/project 
personnel performance plans will identify individual 
development activities as a Key Specific Objective. 

b . Independent Assessment of Key Personnel 
Qualifications . The NAR Team will assess the 
qualifications of key project personnel using the 
following criteria: 

(1) Do key project personnel possess demonstrated 
experience in managing a project? 

(2) Do team members have strong technical knowledge 
pertaining to the area of work? 

(3) Do the key personnel have experience in resource 
management ? 

(4) Is the combination of formal education and 
experience of key personnel adequate? 

(5) What specific training and development in project 
management (specifically in system integration, 
planning, business management, managing people, 
organization/analytical skills, communication, and 
teamwork) does the project team have? 
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CHAPTER 4 


ACQUISITION MANAGEMENT 


References : 


(a) Federal Acquisition Regulation (FAR) 

(b) NASA Federal Acquisition Regulation Supplement 
(NFS) 

(c) Title 41, United States Code, Section 418, 
"Advocates for Competition" 

(d) Title 10, United States Code, Section 2318, 
"Advocates for Competition" 

(e) NMI 5900.1, "NASA Spare Parts Acquisition 
Policy" 

(f) OMB Circular A-109, "Major Systems 
Acquisitions" 

(g) NHB 5600.2, "Statements of Work" 

(h) NHB 5103.6, "Source Evaluation Board Handbook" 

(i) NASA Publication, "Guidance for the 
Establishment and Conduct of Acquisition 
Strategy Meetings" 


1 . 


These policies and processes establish the basis for 

acquisition management. 

2 . POLICIES 

a. As set forth in OMB Circular A-109, the head of each 
agency that acquires major systems will designate an 
acquisition executive to integrate and unify the 
management process for the agency's major system 
acquisitions and to monitor implementation of the 
policies and practices set forth in that Circular. At 
NASA, the Deputy Administrator serves as the agency 
acquisition executive. 

b. A primary goal in developing the acquisition management 
approach shall be to minimize the time and cost of 
satisfying an identified, validated need consistent with 
common sense, sound business practices and the basic 
policies of this instruction. 

c. The acquisition management approach shall evolve through 
an iterative process and become increasingly more 
definitive in describing the relationships of the 
essential elements of a program. Essential elements in 
this context refer to the management, technical, 
resource, procurement and contracting, development, 
testing, training, operations, support and other aspects 
critical to the success of the program. The acquisition 
management approach should also evaluate the need and 
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the acquisition strategy for dual sources for the 
hardware, software, consumable and expendable items to 
support operation throughout the life of the system. 

d. The acquisition management approach and planning should 
begin as soon as NASA's need is identified — at the 
decision to proceed with Phase A — and should integrate 
the efforts of all functions responsible for significant 
aspects of the acquisition. 

e. The acquisition management approach shall be tailored to 
meet the specific needs of individual programs 
consistent with the policies established in the 
documents referenced above. 

f. The acquisition strategy shall: 

(1) Define the mix of system, data, and/or service 
acquisitions that best meet a program/project's 
cost and other requirements; and 

(2) Promote cost containment through innovative 
contracting methods which significantly motivate 
the contractor to meet cost baselines as 
negotiated . 


3 . Ipj.t iai and Subsequent Acquisition Approaches . 

(1) An initial acquisition approach for the proposed 
concept (s) will be developed and approved or 
modified as a result of a decision to proceed with 
Phase A by the responsible PAA. 

(2) The approach should be subsequently developed in 
sufficient detail to establish the combined 
business, technical and managerial approaches which 
will be used to direct and control all elements of 
the acquisition to achieve program objectives. It 
should include a clear description of risk 
elements, including cost, technical, programmatic, 
supportability, performance, and schedule, and the 
corresponding strategies to abate those risks. 

(See Chapter 6) . 

(3) The acquisition management approach will be kept 
current and formally updated at each major program 
decision gate as the system approach and program 
elements are better defined. 

b . Event Driven Acquisition Management and Event Based 
Co ntrac tin g . 
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(1) The objectives of event driven acquisition 
management and event based contracting are to: 

(a) Highlight key developmental events; 

(b) Avoid premature commitment to programs; 

(c) Avoid forcing program/project decisions solely 
because of potential loss of priced contract 
options that may expire on certain dates; and 

(d) Hold the contractor accountable for the cost 
of delays caused by events within the 
contractor's control. 

(2) Event driven acquisition management explicitly 
links program decisions to demonstrated 
accomplishments in development, testing and initial 
operations . 

(3) Event based contracting supports event driven 
acquisition management by imposing the linkages 
between demonstrated performance and corresponding 
program phases. The events set forth in contracts 
must support the appropriate exit criteria for the 
phase or intermediate development events 
established for acquisition management. 

c. Competitive Environment . The acquisition management 
approach for a program will describe plans to develop 
and maintain a competitive environment throughout the 
course of the acquisition. 

(1) Competition at the prime and subcontract level must 
be considered during each acquisition phase. The 
management approaches for acquisition must be 
developed considering the provisions of existing 
statutes and regulations. 

(2) The competition advocate designated by the head of 
each field installation or component with 
acquisition responsibilities will be responsible 
for : 

(a) Assuring that planning for competition is 
accomplished in each acquisition phase, to 
minimize inhibiting factors and to enable 
consideration of reasonable competitive 
alternatives to proposed noncompetitive 
actions; 

(b) Challenging barriers to promoting full and 
open competition, including unnecessarily 
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detailed specifications and unnecessarily 
restrictive statements of work; and 

(c) Otherwise complying with the requirements of 
references (c) and (d) above. 

Tailoring and Concurrency . The acquisition management 
approach will be tailored to match the character of the 
program and allow the most efficient satisfaction of 
individual program requirements, consistent with the 
degree of risk involved. 

(1) Commensurate with risk and affordability 
considerations, such approaches as maintaining 
multiple alternatives in high risk areas, 
competitive prototyping of critical systems, 
subsystems and components, combining developmental 
and operational test and evaluation, dual sourcing, 
and using multi-year procurement should be 
considered . 

(2) The benefits and risks associated with reducing 
lead time through concurrency will be specifically 
addressed in tailoring the acquisition management 
approach . 

(a) Typically there will be overlapping of 
activities associated with the phases of an 
acquisition program. Such overlapping of 
phases is known as concurrency. 

(b) The most common form of concurrency is the 
production of a system while developmental 
activities are still ongoing. The risk in 
such concurrency is that of producing hardware 
or software that might later prove to be 
unsuitable and must then be discarded, 
modified to be useful, or upgraded to a later 
configuration . 

(c) The project manager must balance the risks of 
concurrency with the costs of alternative 
approaches. The risks inherent in the degree 
of concurrency chosen for the program will be 
addressed at the PPAR's (Phase B and Phase 
C/D) . 

Management Requirements on Contractors . In tailoring an 
acquisition management approach, the project manager 
must also address the management requirements imposed on 
the contractor (s) . Process-related requirements that 
are not mandated by statute will be critically examined 
to determine the necessity of use during the formulation 



of an acquisition management approach. 


f. Phased Project Planning . The acquisition management 
approach must be coordinated with and linked to the 
control gates in the entire NASA project life cycle - 
Phase A through Phase E (See Chapter 2) . 

(1) NASA's major systems are normally acquired through 
the use of a multi-phased acquisition strategy 
which supports the entire life cycle of the 
project. Therefore, the acquisition strategy must 
be fully integrated with the program and project 
plans during the planning stages, i.e., prior to 
completion of Phase A. As these plans go through 
their iterative processes, and are updated prior to 
passing through the main decision gates, the 
acquisition strategy and planning also must be 
updated . 

(2) There are several approaches to accomplishing these 
multi-phase major system acquisitions ranging from 
separate acquisition of each phase to competitive 
down-selection of combined phases. The preferred 
technique in NASA is use of a competitive down- 
selection strategy, and the preferred variation of 
this strategy is the "progressive competition" 
approach. The acquisition plan should carefully 
address and document the rationale for the selected 
approach . 

(3) In a progressive competitive down-selection, a 
single formal solicitation is issued prior to Phase 
B for that phase and all subsequent phases. 

Multiple contracts are awarded for the initial 
phase, and a competitive down-selection from among 
these contractors is conducted to determine the 
succeeding phase contractors. Progressive 
competition procedures, when properly planned and 
executed, facilitate the realization of the 
desirable goals of effective and efficient 
acquisition of major systems, preservation of full 
and open competition throughout the entire process, 
and acquisition streamlining. 

(4) Even with these streamlined approaches, Source 
Evaluation Board (SEB) procedures must be used, and 
advance leadtime plans are essential to ensure that 
the entire procurement process is integrated into 
the acquisition strategy. Concurrent with these 
considerations in acquisition strategy, a careful 
look at each step of the process is critical to 
reduce all unnecessary downtime between phases, and 
to run tasks concurrently, where appropriate. 
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Specific reference material is provided below: 

FAR Part 7 Acquisition Planning 

FAR Part 34 Major System Acquisition 
NFS Part 18-7 Acquisition Planning 
NFS Part 18-34 Major System Acquisition 
NFS Part 18-70 Source Evaluation Board 

Lead-time . Advance and continuous planning is critical 
to the success of any project. Early involvement of all 
team players is equally important. In this regard, early 
involvement of the contracting officer, even prior to 
Phase A, is strongly advised. Depending on key program 
features, the contracting officer can provide advice 
regarding critical lead-times that must be planned. 
Typically, the solicitation will be on the street for 60 
calendar days; the SEB process is targeted for 120 days. 
However, time must also be planned for such parallel 
activities as issuing a source sought synopsis and 
evaluating the resultant contractor qualification 
statements; drafting the procurement plan; conducting 
acquisition strategy meetings (ASM's); establishing the 
proposal evaluation criteria; selecting the contract 
type(s) most appropriate given program risk; drafting 
the solicitation document. These are only a few of the 
many activities that must be successfully accomplished - 
prior to issuance of the RFP ' s . These activities are 
not included within the six months lead-time for 
issuance of the solicitation and subsequent SEB 
activities. The team must work together to chart all 
activities involved for a successful procurement, 
including those activities that can run concurrently. 
However, for concurrent activity to be effective, it 
must be planned in advance for each individual project. 

Procurement Plan . Every acquisition shall be adequately 
planned to allow enough time to complete the competitive 
procurement process and award a contract or contracts by 
the required date. The FAR and the NFS should be 
consulted for specific requirements of individual 
procurement plans, but generally included are the 
following elements: 

(1) A description of the procurement (s) , including 
options and later phases contemplated for the same 
project (Phases A through E) ; 

(2) The number of units, delivery schedule, and/or 
period of performance; 

(3) Identification of option provisions, what they must 
contain, and the impact to total contract duration; 



( 4 ) 


A statement addressing whether the contractor (s) 
will be required to comply with detailed 
specifications, meet performance requirements, or 
furnish a level of effort; 

(5) Identification of responsible parties, i.e., name 
of installation and responsible individual; in the 
case of major systems acquisitions, the major 
stakeholders shall be named; 

(6) Total estimated cost of the procurement, including 
options; in the case of major jsystems, include the 
total estimated cost for each phase and link the 
instant procurement (s) to a specific phase (i.e.. 
Phase A - Preliminary Analysis, Phase B - 
Definition, etc.); 

(7) Proposed funding by fiscal year and UPN; 

(8) A description of how competition will be sought, 
promoted and sustained throughout the course of the 
acquisition; 

(9) Recommended type of contract (s) and, where 
appropriate, contemplated profit/fee arrangements; 

(10) Coverage of contractor-owned and Government 
furnished property involved; 

(11) A cost containment plan with goal, list of positive 
and negative incentives, and overall cost 
containment strategy to assure minimal growth; 

(12) Contract management considerations: The 

procurement plan shall address the basic plan for 
post-award management of the pending contract (s). 

At a minimum, it shall address planned delegations 
of contract administration functions to DoD 
contract administration service components, 
delegation of any duties to a Contracting Officer's 
Technical Representative, anticipated 
subcontracting activity, quality assurance 
requirements, oversight of Government property, and 
the contractors' property system, site access and 
site preparation, and the need for any unique 
contract management activity; 

(13) Depending on the complexity of the procurement, 
other areas should also be considered for coverage 
in the procurement plan, including test and 
evaluation requirements and programs, 
logistics/support considerations. Government 
furnished information, environmental 
considerations, security considerations, and the 
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milestones for the acquisition cycle; 

(14) Specific procurement milestones also should be 

addressed, including the following: 

(a) Procurement Plan approval, 

(b) Statement of Work approval, 

(c) Specif ication (s) approval, 

(d) Data requirements approval, 

(e) Completion of acquisition package preparation, 

(f) Purchase request approval, 

(g) Completion and approval of various 
justifications required by statute, 

(h) Issuance of synopsis, 

(i) Establishment of proposal evaluation criteria, 

(j) Issuance of solicitation, 

(k) Establishment of SEB, 

(l) Completion of proposal evaluation, audits and 
field reports, 

(m) Completion of SEB process, 

(n) Beginning and completion of negotiations, 

(o) Contract preparations, review and approval, 

(p) Contract award, 

(q) Post-award contract management, and 

(r) Contract completion 

i. Acquisition Strategy Meeting (ASM) . The ASM is a 

meeting where interested parties resolve major issues 
and agree on the acquisition strategy. An ASM provides 
a forum where technical, financial and procurement 
personnel perform as a team to discuss the key issues of 
a major procurement. The establishment of a 
Headquarters/f ield installation team will engender the 
continuation of successful cooperative endeavors, and, 
at the same time, focus greater attention on the 
planning and management of NASA's acquisitions. It also 
will provide an opportunity for all parties to gain a 
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clear understanding of the requirement and proposed 
business approach; this understanding should simplify 
required reviews and approvals, thereby reducing 
procurement lead-time. The ASM provides an opportunity 
for key program participants to review the logic and 
discipline of the planning process. 

When an ASM is conducted, formal written minutes are 
prepared to summarize the decisions, actions, and 
conclusions of the ASM participants. These approved 
minutes serve as the formal procurement plan required by 
NFS 18-7.103 (a) . ASMs may be held at NASA Headquarters 
or field installations. The following offices will 
normally participate: 

(1) Headquarters: cognizant program office, 

procurement, comptroller, safety and mission 
assurance and the general counsel . 

(2) Installation: project office, procurement, and 

other offices as determined appropriate. 

(3) Major stakeholders shall always attend. 

Post-award Contract Management. Throughout the life of 
the contract (s) , effective post— award contract 
management is critical. Typically, post— award contract 
management will involve all aspects of the program where 
the contractor has performance requirements leading to 
delivery of a design, a component or a system. Some of 
these performance requirements include system 
engineering and project management, configuration 
management and control, logistics support, subcontract 
management, risk management, data management, and cost 
control. Fees paid to contractors need to be consistent 
with contract performance in accordance with NASA 
procurement policy regarding payment of fees. 

(1) NASA will use Contractor Metrics, a system for 
reporting a contractor's in-process performance 
from the NASA project manager through the PAA to 
the Administrator and for reporting the 
Government's assessment of that performance back to 
the contractor. The metrics include cost, 
schedule, technical, award fee, subcontracting 
plan, project manager's assessment and continual 
improvement . 

(2) Technical requirements should be clearly and 
completely defined in each change direction. ^ 

Undef initized contractual actions are to be issued 
on a strict exception basis. NASA's preferred 
method for handling such actions is to use a team 
approach, whereby technical, procurement, resource 
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and contractor personnel concurrently review a 
proposed change prior to any contractual action. 

(3) Every effort should be made to keep the contract 
baseline consistent with the project baseline. 
Effective post-award contract management, involving 
the program stakeholders, is essential to ensuring 
program success. 
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CHAPTER 5 


PROGRAM/PROJECT PLANNING AND CONTROL 


Program/project planning and control is an integral part of 
program and project management. It defines the interrelationships 
of the various elements that comprise a program/project, and 
serves as a process that ties each element to the other. The 
inter-relationships provide a framework for the program/project 
manager to assess, control and track progress through the life 
cycle of a program/project. 

Program/project planning and control establishes a series of 
schedule, technical and resources baselines, which chart the 
course of the program/project and are used to measure deviations. 
Planning and control create the program/project management 
strategy and architecture by defining program organization, roles 
and responsibilities, forums, processes and products keyed to a 
WBS for the program. 

Program/project planning and control balances cost, schedule and 
technical performance commitments through a continuous process of 
data collection, risk assessment, alternatives development, and 
program analysis for the program/project manager to make informed 
decisions. Each of the functional specialties contributes to this 
decision process that manages the risk through judicious 
application of reserves to mitigate the risks. 


This chapter establishes the policies and processes that apply to 
major system development programs and their relationships to the 
other elements of the program. 

SECTION SUBJECT 


A 

B 

C 

D 

E 

F 

G 

H 

I 

J 


Affordability 
Life-Cycle Cost Management 
Systems Engineering 
Work Breakdown Structure 
Schedule Management 
Cost Estimating 
Resource Management 
Configuration Management 
Technical Data Management 
Performance Assessment 
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CHAPTER 5 


SECTION A 
AFFORDABILITY 


1 . PURPOSE 

Affordability constraints and assessments assure program 

life-cycle resource requirements are consistent with Agency 

strategic planning and realistic projections of budget 

availability . 

2 . POLICIES 

a. Individual plans for new major system programs must be 
consistent with realistic projections of budget 
availability and with overall NASA planning and funding 
priorities as derived from the long-range strategic 
planning of the Agency. 

b. Affordability constraints (budget, workforce and 
institutional support) shall be established for the life 
cycle of each project at the completion of Phase A. 

c. Affordability shall be reassessed at each project phase 
decision point beginning with the completion of Phase A. 

d. A project shall not be approved to enter the next life 
cycle phase unless sufficient resources, including 
workforce, are or will be programmed to support 
projected development, testing, production, launch and 
operations requirements. 

e. Program planning shall be structured to assure viability 
at alternate levels of funding consistent with the 
priority of programs/projects. 

f. Performance parameters and key requirements necessary to 
assure continuing affordability throughout all phases of 
the project life cycle shall be specified in the PCA, 
and control/measurement systems shall be implemented 
during Phase C/D to assure their achievement. 


a . 


Program /Project Cost Estimating . In order to enable 
the affordability assessments to be made at the Agency 
level, program/projects must develop and implement an 
effective cost estimating capability for life cycle 
costs (LCC) . (See Figure 5-A-l) 


5 -A- 1 




Figure 5-A-l . Program/Pro ject Costs 

(1) Program/project life-cycle cost assessments must 
show annual resource requirements. 

(2) Civil service and institutional support 
requirements must be considered. 

(3) Program/project life-cycle cost assessments must 
include any required resource demands from other 
NASA programs . 

b. The PAA is required to explicitly address affordability 
at the PPAR. The analysis shall: 

Identify cost and benefits of alternate levels of 
requirements and capability for the proposed 
alternative; 

Identify how program structure, schedule planning 
and acquisition strategy support milestones of a 
viable program at reduced levels of funding 
availability; 

- Address the relative priority of this 

program/project to ongoing programmatic and 
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institutional activities; and 

Address the sources of the required resources 
(tradeoffs within the mission area or Agency, 
commitment of new resources or other sources) . 

c. Agency Affordability Constraints . The PMC shall use 
affordability as a key evaluation criteria in 
recommending initiation and continuation of development 
programs . 

d. Progra m/Proiect Management Within Constraints . 
Performance parameters and key cost assumptions 
necessary to assure continuing affordability in later 
phases of the life cycle should be specified in the 
program/project commitment and control system, and 
should be established and implemented throughout the 
development phase to assure their achievement . 
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CHAPTER 5 


SECTION B 

LIFE-CYCLE COST MANAGEMENT 


1 . PURPOSE 

Life-cycle cost management, which transcends traditional 
design-to-cost objectives, is used to predict, assess, 
review, negotiate, monitor and control development and other 
life cycle costs for a project. This enables the program and 
project managers to ensure that appropriate trades are made 
among total costs, acquisition costs, ownership costs, 
schedules, risk and performance. 

2. POLICIES 

a. Life cycle cost shall be estimated, assessed and 
controlled throughout each project life cycle. 

b. The PAA will identify a common set of groundrules and 
assumptions for specification and estimation of LCC and 
its components. The PAA will ensure that groundrules, 
assumptions and methods used by the CFO/Comptroller to 
determine the differences between the Estimate at 
Completion (EAC) and the PCC are available to the 
program and project managers. 

c. Life-cycle cost considerations shall be integrated into 
the design and development process including the formal 
change control process. 

3 . PROCESSES 

Life-cycle costing shall be integrated into Program/Project 
Formulation to project and assess the LCC of alternative 
implementations. This critical capability must be maintained 
and exercised during trade studies and formal change control 
assessments carried out as a part of any LCC management 
program during Project Implementation. 

a. Use of this capability early in the project cycle 
(Phases A and B) during requirements analysis and 
system-level trades should focus on the LCC effects of 
varying mission design/mission effectiveness parameters. 
Such high-level trade studies help identify whether a 
slight relaxation of performance requirements could 
result in a significantly cheaper system or whether a 
small increase in LCC resources could produce a 
significantly more effective one. 

b. Use of this capability during Project Implementation 


5-B-l 



should focus on assuring the LCC effects of refinements 
in the system design, operations concept, and/or 
associated downstream processes (such as fabrication, 
verification, operations and support, and disposal) are 
consistent with the PCC and the DCC component of the 
PCC. 

c. For major changes in system design, operations concept, 
and/or associated downstream processes, LCC effects must 
be projected and submitted as a part of any formal 
change control request . 

d. Projecting the LCC effects of a change in system design, 
operations concept, and/or associated downstream 
processes requires the involvement of a variety of 
technical and engineering specialty disciplines. The 
program and project managers must make LCC management an 
indistinguishable part of the PPM effort. 
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CHAPTER 5 


SECTION C 

SYSTEMS ENGINEERING 


These policies and processes establish the basis for 
integrating the technical efforts of the entire project 
(system) design team to meet cost, schedule and performance 
objectives. These efforts are meant to create a satisfactory 
design solution that encompasses the system and its 
associated fabrication, verification, operations and support, 
and disposal processes. 

2. POLICIES. 

a. Systems engineering, including the processes sometimes 
called "project engineering", shall be applied 
throughout the program/project life cycle as a 
comprehensive, iterative technical and management 
process to: 

(1) Translate an operational need into a system meeting 
that need within acceptable cost, schedule and risk 
parameters through a systematic, concurrent 
approach to integrated design of the system and its 
related downstream processes — fabrication, 
verification, operations and support, and disposal. 

(2) Integrate the technical input of the entire 
development community and all technical 
disciplines, (including engineering specialty 
disciplines such as reliability and logistics) into 
a coordinated effort that meets all established 
cost, schedule and performance objectives, with 
acceptable risk. 

(3) Ensure the compatibility of all functional and 
physical interfaces (internal and external) , and 
ensure that the system definition and design 
reflect the requirements for all system elements — 
hardware, software, facilities, personnel and data. 

(4) Identify and characterize program/project risks and 
develop risk mitigation approaches as appropriate 
to the level of risk selected for the 

pro ject / system . 

(5) Provide information, such as trade studies and 
project (system) status assessments, to support 
management decision making. 
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b. The primary roles of the NASA and contractor project 
offices in the systems engineering process shall be 
management and execution of systems engineering, 
respectively. 

3. PROCESSES 

a. The project office will work with the user or user's 
representative to establish the feasibility of 
operational requirements and identify the critical 
operational characteristics and constraints (see Chapter 
10 ) . 

b. A disciplined user requirements collection and system 
design methodology will be used to convert and refine 
these requirements into detailed design specifications. 
This methodology should provide traceability of design 
products and operational products to user requirements. 
This methodology shall include verification of the 
adequacy of designs and operational processes with 
respect to meeting requirements. 

c. A rigorous process will be established to balance design 
specifications so as to optimize the system design. 

This process will provide for concurrent engineering 
among members of the design team to ensure that all 
necessary engineering design elements and downstream 
processes (such as fabrication, verification, operations 
and support, and disposal) present their design issues 
in a timely manner. Cost management objectives shall be 
considered as a design parameter in this process. 


5-C-2 



CHAPTER 5 


SECTION D 

WORK BREAKDOWN STRUCTURE 


1 . PURPOSE 

These WBS policies and processes establish the essential 
framework for project: technical planning, scheduling, cost 

estimation and budgeting; defining the scope of statements of 
work and contracts; developing documentation products 
(including specifications and drawings) ; and program/project 
status reporting and assessment (including integrated 
cost /schedule performance measurement) . 

2 . POLICIES 

a. The WBS shall: 

(1) Define all the work necessary to complete the 
project; 

(2) Be a product-oriented, hierarchical division (tree) 
of deliverable items (hardware, software, 
information) and associated services; and 

(3) Relate the elements of work to each other and to 
the end item (system or product) . 

b. A WBS shall be developed for each project and for each 

individual contract . 

(1) A preliminary project WBS will be developed in 
Phase A to define the top levels of a WBS for the 
entire project (system) life cycle. Normally, this 
life cycle WBS will be in two parts — one for the 
acquisition cycle of the system being acquired 
(Phases A through D) , and one for the operations 
and support phase (Phase E) . 

(2) A final project WBS will be prepared by compiling 
the elements of the contract WBS(s) with the 
preliminary project WBS. 


3 . PROCESSES 

a. Project WBS . The project WBS should contain the 

project's Product Breakdown Structure (PBS), with the 
specified prime product (s) at the top, and the systems, 
segments, subsystems, etc. at successive lower levels. 

At the lowest level are products such as hardware items, 
software items and information items (e.g., documents, 
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databases, etc.) for which there is a cognizant engineer 

or manager. 

(1) Branch points in the hierarchy should show how the 
PBS elements are to be integrated. The WBS is 
built from the PBS by adding, at each branch point 
of the PBS, any necessary service elements, such as 
management, systems engineering, integration and 
verification, and integrated logistics support. 

(a) The family of specifications and drawings 
resulting from the progressive steps of 
systems engineering will conform to the WBS. 

(b) Integrated logistics support will be 
accommodated in the appropriate WBS elements. 

(c) Software will be accommodated in the 
appropriate WBS elements. Software will be 
identified with the hardware it supports. Any 
aggregations of WBS elements required for 
software management and reporting will be 
accomplished by summation of relatable 
elements of the project WBS. 

(d) Overall system software to facilitate the 
operation and maintenance of the computer 
systems and associated programs (e.g., 
operating systems, compilers, and utilities) 
and applications software that interfaces with 
more than one equipment item will be called 
out at the appropriate WBS level . 

(e) If several WBS elements require similar 
equipment or software, then a higher level WBS 
element can be defined to perform a block buy 
or a development activity (e.g., "System 
Support Equipment") . 

(2) A project WBS will be carried down to the level 
appropriate to the risks to be managed. The 
appropriate level of detail is determined by 
management's desire to have visibility into costs, 
balanced against the cost of planning and 
reporting . 

(3) Extensions of the WBS will be consistent with a 
product-oriented approach, but can be tailored to 
the specific project. 

b. Contract WBS . 

(1) Contractors must have a Contract WBS (CWBS) , which 
is appropriate to the contractor's needs to control 
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costs. A summary CWBS, consisting of the upper 
levels of the full CWBS, is usually included in the 
project WBS to report costs to the project office. 

(2) From the initial project WBS, preliminary CWBS (s) 
for individual contracts will be negotiated with 
the contractors involved. The CWBS will be 
extended to lower levels by the contractor in 
accordance with the product-oriented approach. 

c. WBS Identification . WBS elements must be identified by 
title and by a numbering system that performs the 
following functions: 

(1) Identifies the level of the WBS element; 

(2) Identifies the higher level element into which the 
WBS element will be integrated; 

(3) Shows the cost account number (if any) of the 
element . 

d. WBS Dictionary . A WBS must have a companion WBS 
dictionary that contains each element's title, 
identification number, objective, description, and any 
dependencies (e.g., receivables) on other WBS elements. 
This dictionary provides a structured project 
description for orienting both project staff and others. 
It fully describes the products and/or services expected 
from each WBS element, and should be consistent with any 
contractor statement of work. 
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CHAPTER 5 


SECTION E 

SCHEDULE MANAGEMENT 


1 . PURPOSE 

Schedules establish interrelationships and time-phasing of 
activities and events essential for the timely and effective 
implementation of a program/project. The goal of scheduling 
is to provide a framework to time-phase and coordinate 
activities into a master plan in order to complete the 
program/project within the established constraints and 
balanced cost, schedule and performance commitments. 

The Schedule Management (SM) function establishes, monitors 
and maintains the baseline master schedule and derivative 
detailed schedules. It establishes and operates the 
scheduling system and defines the schedule format, content 
and symbology, and control processes. A critical component 
of the SM function is the selection, in response to the 
program logic, of key progress milestones and indices for 
measuring performance and indicating problems. 

2 . POLICIES 

a. The Integrated Program Master Schedule (IPMS) will 
identify all milestones controlled by the PAA. Major 
development programs will establish commitment 
milestones between the PAA and the Administrator. The 
IPMS will be derived from the MNS . 

b. IPMSs will consist of at least one controlled milestone 
per fiscal year. 

c. Program/project schedules will conform to the 
program/project WBS . 

d. Program and project schedules will be used as a 
controlled baseline for regular status reporting. 

3. PROCESSES 

a. A preliminary IPMS will be developed as part of Phase A. 

b. The program/project schedule will be developed based on 
the program/project WBS. 

c. A critical path will be established and maintained for 
all programs/projects. 
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d. Phase C/D contractor schedules will be reported at 
sufficient detail that visibility is maintained at least 
to the level of the critical path, with full cost, 
schedule and technical reporting made on critical path 
elements. This schedule reporting will be consistent 
with established procedures including: 

(1) Use of standard symbology. 

(2) Use of automated tools is highly encouraged. 

e. To the extent possible, program schedules should flow 
from the system being used by the contractor. 

f. Program schedules for programs subject to PCAs will be 
reviewed : 

(1) Quarterly by the PMC, 

(2) Annually by an IAR team, and 

(3) As required in support of NAR's, PPAR's, CR's, and 
MR's. 
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CHAPTER 5 


SECTION F 
COST ESTIMATING 


1. PURPOSE 

These policies and processes establish the basis for the 
production and review of cost estimates in support of NASA 
programs . 

2. POL I C I ES 

a. Life-cycle cost estimates shall be prepared in support 
of : 

(1) The program commitment process; and 

(2) Major reviews including NAR's, PPAR’s, IAR's, CR's, 
and MR’s at L-2 and L-l . 

b. Cost estimates prepared in support of the above shall 
be : 

(1) Explicitly based on the program objectives, 
operational requirements and contract 
specifications for the system, including plans for 
matters such as launch vehicles, unique facilities 
and project unique support costs; 

(2) Comprehensive in character, identifying all 
elements of additional cost that would be entailed 
by a decision to proceed with development, 
production and operation of the system; 

(3) Neither optimistic nor pessimistic, but based on a 
careful assessment of risks and reflecting a 
realistic appraisal of the level of cost most 
likely to be realized; 

(4) Correlated to a well-defined technical baseline and 
a detailed schedule; and 

(5) Inclusive of estimated savings, if any, resulting 
from private-sector or international participation. 

3. PROCESSES 

a. As is warranted by the issues involved, a 

program/project office cost estimate and/or a cost 
estimate made by an independent review team may be 
required in support of any of the instances listed in 
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paragraph 2. a. above. In these instances, the 
requirements for cost estimates shall be appropriately 
tailored for the purposes of the review as established 
by the official requesting the estimate. 

Two separate cost estimates shall be prepared prior to 
initiation of design and development (Phase C/D) : 

(1) One estimate shall be prepared by the 
program/project office using appropriate estimating 
techniques to establish resources input in terms of 
labor, materials, and other direct and indirect 
costs and fees. 

(2) A second estimate shall be prepared by an 
independent cost estimating team using appropriate 
estimating techniques. 

All program cost estimates shall project total cost 
through the life cycle (see Figure 5-A-l), shall be 
summarized by program phase in accordance with the 
current WBS, and time-phased by government fiscal year 
(FY) . 

For each cost estimate, all major groundrules and 
assumptions regarding key cost parameters will be 
documented and justified. This should include 
assumptions regarding technology readiness, use of off- 
the-shelf hardware, complexity, use of in-house civil 
service resources, etc. 

New start estimates shall be prepared in constant FY 
dollars accrued cost based on the expected new start 
program year. 

(1) The Office of the Comptroller shall maintain, and 
update at least annually, a New Start Research and 
Development Inflation Index ("New Start Index") 
that shall be used to convert to and from constant 
fiscal year dollars and real year dollars, for new 
start estimates. 

(2) When used to compare competing alternatives, e.g., 
different proposals from the same or competing 
contractors, the net present value of each 
alternative shall be used by discounting the real 
year cost plan using the discount rate and 
methodology guidance consistent with reference (a) . 

In order to assist in the development and refinement of 
cost estimating techniques, at the completion of Phase 
D, the program manager shall report time-phased elements 
of cost and technical parameters in a format specified 
by the CFO/Comptroller. 



g. Each program/project will maintain a history of the cost 
estimates that is traceable to the program assumptions 
and the external influences as part of the permanent 
program record and available for subsequent audit. 
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CHAPTER 5 


SECTION G 

RESOURCE MANAGEMENT 


The Resource Management (RM) function is comprised of : planning, 

monitoring, and controlling cost, workforce, and facility 
requirements; correlating these requirements to technical and 
schedule performance; and comparing these parameters to baselines 
established for the program. The RM function establishes, 
monitors and updates budget, commitment, obligation and cost 
baselines, as well as the workforce baseline. This includes 
generating resource impact estimates for major changes, 
alternative planning, schedule adjustments, new requirements, 
rebalancing between elements, and/or budget limitations. The key 
elements of RM are: 

Resource Requirements, 

Budget Development and Administration, 

Funds Control, and 

- Contractor Financial Reporting and Performance 
Measurement Systems . 
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RESOURCE REQUIREMENTS 


1 . PURPOSE 

a. To determine the level of resources required for the 
execution of the program/project throughout the life 
cycle . 

b. To determine the institutional resources requirements 
that occur outside the program/project life cycle, but 
are necessary to the efficient completion of the program 
objectives . 

2. POLICIES 

a. The PAA shall assure that all elements of cost of a 
program are accurately estimated, consistent with the 
program/project technical and schedule plans and are 
submitted for budget consideration. These estimates are 
updated as necessary throughout the life of the 
program/project . 

b. The CFO/Comptroller shall assure that resources 
requested by the PAA conform to existing standards, laws 
and regulations. 

3. PROCESSES 

a. The program/project manager will prepare resource 
estimate in accordance with the procedures in Chapter 
5.F. 

b. Estimates will be included for all elements of cost 
within the program life cycle. (See Figure 5-A-l) 

(1) Estimates will be time phased by FY. 

(2) Estimates should be projected by WBS element at the 
appropriate level, and by organizational element at 
the appropriate level. 

c. Additional estimates will be projected by FY that are 
not included within the program life cycle. These 
include : 

(1) Civil service workforce full-time equivalents 
(FTE) , and 

(2) Undistributed facility usage levels. 
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BUDGET DEVELOPMENT AND ADMINISTRATION 


1 . PURPOSE 

a. Ensure the implementation of approved programs and any 
proposed new programs are consistent with Agency 
planning and projected resources availability. 

b. Develop recommendations that support priorities of 
Agency management, contain a reasonable estimate for the 
work proposed, and have a reasonable chance for 
approval . 

c. Support the recommended budget submission to OMB and 
Congress including documentation, justification, 
hearings and responses to questions. 

d. Ensure that program execution during the operations year 
is consistent with the approved plan. 

e. Monitor progress against the approved plan. 

f. Reallocate resources if necessary. 

2 . POLICIES 

a. NASA will prepare and submit a program budget each year 
in accordance with the procedures contained in 
references (b) and (c) . Each PAA is responsible for 
developing estimates for each program in accordance with 
the Agency Wide Coding Structure that will support the 
request to OMB and Congress for funding authority for 
each phase of the project life cycle. 

b. Each PAA is responsible for preparation of the necessary 
support documentation and to act as an advocate for his 
or her proposed new starts, on-going programs and 
adjustments to baselines. 

c. The CFO/Comptroller is responsible for the release of 
resource allocations and resources authority in 
accordance with the approved operating plans. 

d. Each PAA will monitor the progress of his or her 
programs to assure that commitment agreements are met, 
or that variances are identified and resolved at the 
earliest possible time. 

3 . PROCESSES 

a. Annually, the CFO/Comptroller, after consultation with 
the Administrator, will issue program guidelines and 
budget submission instructions to the PAA. The PMC will 
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review all new Phase B proposals and provide guidance on 
those that can reasonably be expected to be funded. 

b. In accordance with the instructions from the 

CFO/Comptroller, the PAA will prepare and forward a 
program budget request for each approved program under 
his or her cognizance. See Figure 5-G-l . 

(1) Using the CFO/Comptroller guidelines as a basis, 

the PAA will request a Program Operating Plan (POP) 
from the field installations for each program under 
his or her cognizance, as well as the funds 
required for program research, technology and 
program support . 

(a) The field installation project manager will 
prepare a POP that will be time-phased 
according to the CFO/Comptroller and PAA 
instructions, and: 

Realistically projects the NOA and 
cost required to proceed according 
to the Project Plan. 

Identifies any over-guideline 
requirements and associated impact 
statements assessing the risk to 
technical performance or program 
schedules due to lack of required 
funds . 

Is structured to minimize the risk 
associated with the normal 
fluctuations in available funding 
as a result of the authorization, 
appropriation and apportionment 
process . 

(b) The project manager will include a projection 
of the total LCC of the project, which should 
be made a part of updated Project Plans, 
commitment agreements and other documentation, 
when required. 

(2) If appropriate, the PAA will submit requests for 
program authority for programs entering Phase B or 
Phase C/D. 

(3) If necessary, the PAA will request program authority 
that exceeds either the program guidelines issued by 
the CFO/Comptroller or the PCC as an increment in 
excess of the budget guidelines. 
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• KEY DECISION POUTS 


Figure 5-G-l Program Budget Process 

c. Once approved by the Administrator, the PAA will prepare 
the necessary documentation to support the advocacy of the 
NASA Budget Request to both the OMB and Congress . 

d. If necessary, the CFO/Comptroller, in consultation with 
the Administrator, will make adjustments to the levels 
submitted in the NASA Budget Request to reflect changes 
enacted by Congress. This approved budget will form the 
basis for the Agency operating plan. 

e. When appropriated and authorized by Congress, and 
apportioned by the OMB, the CFO/Comptroller will allocate 
funds to the programs in accordance with the Agency 
operating plan. 

f. Each PAA will assure the day-to-day execution and 
monitoring of his or her programs within the Agency 
operating plan and report variances periodically. 
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( 1 ) 


Variance notifications should address the level to 
which program commitments are threatened and options 
for recovery, if necessary. 

(2) The CFO/Comptroller will reallocate funds as 

necessary after obtaining necessary Agency and 
Congressional approvals. 
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FUNDS CONTROL 


Funds Control assures use of program and institutional funds 

for the purposes authorized and appropriated by Congress and 

apportioned by the OMB. 

2. POLICIES 

a. The NASA Administrator shall execute programs within the 
funding constraints of Congress and the President. 

b. The CFO/Comptroller shall control and distribute all funds 
to the extent funds are available through the 
apportionment of the OMB. The authority to further 
control these funds may be delegated to the Comptrollers 
of NASA field installations. 

c. The PAAs shall execute the programs under their cognizance 
within allocated funds. 

d. The NASA Inspector General shall review fiscal 
transactions and program execution to assure compliance 
with the NASA appropriations and authorizations, as well 
as the Space Act and other laws and regulations. 

3 . PROCESSES 

a. Resources allotments (504) are issued by the CFO/ 
Comptroller to the appropriate field installation from 
funds apportioned by the OMB. (See Figure 5-G-2 . ) 

b. Resources authority (506 Green) is issued to the PAA in 
accordance with the Agency operating plan. 

c. Resources authority (506 White) is issued to the field 
installation by the PAA. 

d. Each field installation maintains an internal control 
system to assure that authority is available before 
commitment, obligation, cost or disbursement of funds, 
maintaining data in a manner that facilitates audit of all 
transactions . 


b-n- i 



CFO/Comptroller 



Figure 5-G-2 Funds Control Process 
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CON TRACTOR FINANCIAL REPORTING AND PERFORMANCE MEASUREMENT SYSTEMS 


1 . PURPOSE 

These policies and processes establish the basis for the 
application of cost reporting and performance measurement 
requirements to contracts under major programs and projects. 
The purpose of these requirements is to provide contractor 
and NASA program/project managers with data sufficient to 
monitor execution of their program/project and to: 

a. Assess progress against plans and complinace with 
technical, schedule, and cost baselines and commitments, 
and 

b. Provide early warning of potential problems. 

2 . POLICIES 

a. Contractor cost reporting and performance measurement 

requirements shall be applied to contracts in accordance 
with references (e) , (f) , and relevant field 

installation management instructions. 

b. Contractors' internal accounting and reporting systems 
shall include policies, procedures and methods that are 
designed to accomplish the requirements in reference 
(f) . 

c. Contractor reporting must be of sufficient detail to 
allow the PAA to: 

(1) Assess project progress and conformance to the PCA. 

(2) Fulfill the requirements of NMI 2340.3, 
"Implementation of Contractor Metrics" (reference 
(m) ) . 


3. PROCESSES 

a. Contractor cost reporting and performance measurement is 
required and will be accomplished in accordance with 
references (e) , and (f), and will be of sufficient depth 
to support the required program control, verification 
and internal and external reporting requirements of 
NASA . 

(1) The contractor must report to a level that will 
allow the program/project manager to review the 
cost expended on the program/project in relation to 
the schedule and technical progress and determine 
the critical elements of risk to the 
program/project . 
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(2) The program/project manager must be able to report 
progress compared to the Project Plan. 

(3) The PAA must be able to report compliance with the 
PCA . 

b. Contractor cost data is used within NASA to fulfill 
financial management, contract management, program 
control and resources acquisition functions and 
therefore must be reported accurately by the contractor 
and entered into NASA systems in a timely fashion. 

Cost, schedule and technical performance data provided 
to NASA will be summarized directly from the same 
systems used for internal contractor management. 
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CHAPTER 5 


SECTION H 

CONFIGURATION MANAGEMENT 


1. PURPOSE 

The Configuration Management (CM) function establishes a 
formal and disciplined system for identifying, controlling, 
accounting and verifying hardware and software requirements 
and configuration through the life cycle. This function 
provides a disciplined approach for control of plans, 
requirements and the configuration of hardware and software 
throughout the life cycle of the program/project. The 
function consists of four distinct practices: 

Identification - The definition and establishment 
of the baseline plans, requirements and 
configuration items to be controlled; 

Control - The formal process used to assure 
discipline in making changes to the baseline. 

This control is effected through formal 
configuration control boards. 

Accounting - Definition and reporting of the exact 
baseline on a continuing basis and provision of a 
clear audit trail from the authorization of 
changes to the affected documentation and 
products. Accounting provides the single 
authoritative source for definition of the 
configuration baseline. 

Verification - Verification that the baseline 
configuration requirements have been incorporated 
into products and are tested accordingly. 

2. POLICIES 

a. An effective CM program shall be implemented at the 
earliest stages of all projects and programs. The 
results of Phase A should include a documented CM plan 
for implementation in Phase B. This then becomes the 
basis for all follow-on phases for a configuration 
item's life cycle. 

b. It is the program/project managers responsibility to 
ensure that CM policies, processes and procedures are 
implemented as early as possible for all programs within 
the purview of this Instruction. 

c. The established CM system must enable: 
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(1) Identifying, documenting and verifying the physical 
and functional characteristics of a configuration 
item. 

(2) Ensuring that all documented configuration item 
requirements are traceable and verifiable to their 
origin and their lower tier allocation and to its 
origin. A parent-child relationship of 
configuration item requirements shall be 
established and maintained for the life cycle of 
the configuration items. 

(3) Controlling changes to an item and all of its 
associated documentation in a synchronized manner. 

(4) Status accounting and reporting the status of an 
item's configuration and its related documentation, 
including documentation of the configuration 
dependent activities (spares, handbooks, contracts, 
test documentation etc.). 

(5) Auditing the configuration item and its 
configuration identification. 

d. Configuration management shall be applied to any item: 

(1) Developed wholly or partially with NASA funds, 
including non-developmental items when the 
development of technical data is required to 
support off-the-shelf equipment or software, or 

(2) Designated for CM for the reason of integration, 
logistics support, operations support, interface 
control or safety critical considerations. 


3. PROCESSES 

a. Configuration Management Procedures . 

(1) Configuration management procedures shall be 
tailored to be consistent with the complexity, 
criticality, quantity, size and intended use of the 
items. Standard processes shall be used through 
the tailored application of relevant military 
standards (references (g) through (j)), adapted to 
specific program characteristics. 

(2) Program/project managers shall apply and maintain 
CM activities during all phases of the program. 
These activities shall be transferred to the user, 
logistics or identified sustaining engineering 
organization upon configuration item management 
transfer from the program/project manager. 
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(3) When the program development team includes non-NASA 
organizations (e.g., international participants or 
partners) , the designated NASA lead institution or 
organization shall develop mutual agreements and a 
standardized set of CM procedures and processes, 
which are acceptable to all participants. Such 
processes shall function within the prescribed NASA 
restrictions of technical information exchange and 
data transfer. 

b. Configuration Items . A configuration item is defined as 
an aggregation of hardware and/or software and related 
documentation that satisfies an end use function and is 
designated by NASA for separate CM. This includes any 
item required for logistics support and designated for 
separate procurement . 

(1) Configuration items shall be directly traceable to 
the WBS . 

(2) Computer hardware and software shall be treated as 
configuration items. Computer software shall be 
treated as configuration items throughout the life 
cycle of the program regardless of how the software 
shall be stored (e.g., read-only memory devices, 
magnetic tape or disc, compact disc, non-volatile 
random access memory, laser disc devices) . 

c. Configuration Baselines . Configuration baselines shall 
be used to ensure an orderly transition from one major 
commitment point to the next. These commitment points 
are normally major program/project controlled milestone 
points (See Chapter 2) . Configuration baselines 
(functional, allocated, and product) may be identified, 
documented, and maintained in accordance with MIL-STD- 
490 and/or MIL-STD-973 (reference (g) and (h) ) , or other 
applicable sources. 

d. Configuration Identification . Configuration 
identification may be prepared in the form of technical 
documentation in accordance with MIL-STD-490 and MIL- 
STD-973 (reference (g) and (h) ) , or other applicable 
sources . 

e. Change Control . Configuration changes may be controlled 
in accordance with MIL-STD-973 (reference (h) ) , or other 
applicable sources, to identify the impact of proposed 
changes to functional and physical characteristics and 
approved configuration identification. 

f. Configuration Status Accounting . Configuration status 
accounting shall provide closed-loop tracking of 
configuration identification changes and document the 
configuration of items. Configuration status may be 
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documented through tailored application of MIL-STD-973, 
DoD-STD-2167 and DoD-STD-2168 (references (h) , (i) and 
(j)), or other applicable sources. 

g. Configuration Item Development Records . Configuration 
records for each configuration item shall be established 
when the applicable configuration baseline is 
established. These records shall include both current 
and historical information to ensure traceability from 
the initial baseline requirement is maintained. 

h. Configuration Audits . Configuration audits shall verify 
and document that the configuration end item and/or 
configuration item and its configuration identification 
agree (as-designed to as-built comparison) , are complete 
and accurate, that all waivers and deviations are 
identified, and satisfy program requirements. MIL-STD- 
973, DoD— STD— 2 1 67 and DoD-STD-2168 (references (h) , (i) 
and (j)) contain procedures for conducting configuration 
audits . 
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CHAPTER 5 


SECTION I 

TECHNICAL DATA MANAGEMENT 


1. PURPOSE 

The technical data management function establishes a formal 
and disciplined system and responsibilities for generating, 
identifying, controlling, distributing and reporting of 
engineering and technical management information required to 
support a program/project. Technical data management 
policies and processes are provided to ensure that the most 
cost effective methods and procedures are established for 
identification, procurement, receipt, acceptance and 
maintenance of technical data procured from the contractor or 
prepared and delivered within NASA. 

2. POLICIES 

a. The NASA project office having management responsibility 
for an item shall ensure that the Government has 
complete access to the data necessary to support the 
essential requirements of all users throughout the 
item's life cycle. This access may be achieved by: 

(1) Procuring, storing and maintaining the necessary 
data in a Government data repository; or 

(2) Procuring access to the data through a contractor 
integrated technical information service. 

b. Only the minimum data needed to permit cost-effective 
support of research, development, production, 
cataloging, provisioning, training, operation, 
maintenance and related logistics functions over the 
life cycle of the item shall be acquired. 

c. Data shall be ordered in contractor format unless the 
Government format is necessary or more cost-effective. 
Maximum use will be made of commercial technical 
manuals, or their modifications, that meet NASA 
requirements . 

3 . PROCESSES 

a . Establishing Data Requirements 

(1) A technical data package shall include all 

engineering drawings, associated lists, process 
descriptions, and other documents which define the 
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physical geometry, material composition, 
performance characteristics, manufacture, assembly 
and acceptance test procedures. 

(2) User data requirements shall be established by use 
of a "Data Call" to all potential users (per 
reference ( j) ) . 

(3) Standard Data Requirements Descriptions (DRDs) or 
Data Item Descriptions that exceed the requirements 
of the data needed shall be tailored. Tailoring 
may be accomplished to accept contractor format, or 
reduce the scope through deletion, unique 
modification or selection of existing words, 
paragraphs or sections. 

(4) Contract provisions shall: 

(a) Ensure that contractors and subcontractors 
prepare and update technical data packages as 
an integral part of their design, development, 
and production effort; and 

(b) Define the contractor's responsibility for 
accuracy and completeness of technical data 
packages and technical manuals. 

(5) All technical data and technical manuals shall be 
updated to reflect approved design changes and made 
available concurrent with the implementation of the 
change . 

(6) Contract deliverable data shall be prepared and 
used in electronic form unless it is not cost- 
effective for the Government. Maximum use should 
be made of available contractor automated 
databases . 

(7) When options are established for delivery of 
digital data, the program office shall ensure that 
all the recipients of the electronic data have the 
necessary capability to receive, store and maintain 
the data. 

(8) Logistics support analysis data shall be used to 
the maximum extent to define and develop source 
data for technical manuals. 

b. Planning for New Technical Manuals . Plans shall be 

developed for technical manuals to ensure support to all 

end items, system, system component, support equipment 

or test support equipment. These plans shall: 
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(1) Provide means for ensuring the technical accuracy 
and adequacy of technical manual content. 

(2) Provide for the optimum number and types of 
conventional publications and other media such as 
audiovisual systems, tape, disc or other electronic 
devices; and 

(3) Establish a clear definition of: 

(a) Contractor responsibility for accuracy and 
completeness of technical manuals; and 

(b) Contractor and NASA participation in 
validation and verification. 

c. Data Acquisition Documents . Specific requirements for 
the preparation of deliverable data or for record 
keeping are to be documented in specifications, 
standards, and DRDs, collectively known as data 
acquisition documents. 

(1) Data requirements in solicitations and contracts 
shall be reflected in DRDs. 

(2) DRDs shall not be used to delineate requirements 
for technical manuals for systems, configuration 
end items, subsystems components, or support 
equipment. These manuals shall be acquired by line 
item and have an exhibit attached to the 
acquisition document. 

(3) The acquisition of technical manual administrative 
and/or management data, such as status reports, 
validation plan schedules, and manuals other than 
those to support a configuration end item and/or 
system shall be acquired by DRD . 

d. Ordering, Delivery, Inspection and Acceptance of Data . 

Data shall be ordered, delivered, inspected and accepted 
in accordance with the FAR and NASA FAR Supplement . 

e. Rights in Data . Acquisition of rights in technical data 
shall be in accordance with the FAR and NASA FAR 
Supplement . 

f. Warranty of Data . Acquisition of data warranties shall 
be in accordance with the NASA FAR Supplement . 

g. Distribution Statements on Technical Data . Technical 
data shall be marked in accordance with the NASA FAR 
Supplement and MIL-STD-1806 (reference (1)) to denote 
the extent to which the data may be distributed without 
further approval of the controlling NASA office. 
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h. 


Data Repositories . Technical data packages, software 
media and associated data shall be received, 
inventoried, inspected, accepted, indexed, stored and 
managed to provide maximum accessibility to NASA 
projects, programs and installations, and to ensure that 
contractor data rights are protected. 

i. Release of Data . To the maximum extent allowable by law 
and regulation, NASA field installations shall provide, 
or make available, requested data in accordance with 
applicable portions of the FAR and NASA FAR Supplement. 
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CHAPTER 5 


SECTION J 

PERFORMANCE ASSESSMENT 


1- PURPOSE 

Program assessment correlates the impacts of cost, schedule 
and technical performance on the ability to successfully meet 
the commitments contained in the various program/project 
control documents and agreements. 

2. POLICIES 

a. The program/project manager shall install and operate an 
effective system of performance asessment . 

b. The PAA shall institute a system of routine controls to 
assure optimal use of program resources on a particular 
program/project . 

c. The CFO/Comptroller shall independently validate the 
performance of the program/project throughout its life 
cycle . 

3. PROCESSES 

a. The program/project manager will develop the necessary 
tools to monitor and correlate the cost, schedule, and 
technical performance elements of the program. 

(1) In order to effectively analyze performance, 
meaningful cost, schedule and technical performance 
baselines must be established: 

(a) In conformance with the program WBS at a level 
sufficient to assure visibility into the 
critical path of the program; and 

(b) Consistent with higher-level program 
commitments . 

(2) The "earned value" methodology for correlating 
accrued cost to work accomplished is required to 
perform this assessment. 

(3) The project office is encouraged to utilize 
standard contractor reporting systems that will 
provide the required data in sufficient detail for 
analysis purposes. (See Chapter 5.g) . 


b-J-l 



(4) Each program/project manager shall establish a set 
of cost, technical and schedule metrics related to 
program/project commitments. These metrics shall 
include a control target and tolerance band around 
the time-phased plan that establishes acceptable 
values given the program/project's phase of the 
life cycle. 

(5) The program/project manager shall periodically 
report the metric values of these trends, 
consistent with controlled activities and 
commitments . 

b. The cost, schedule and technical commitments and 
associated control targets established in PCA documents 
will be the basis for triggering review actions by 
commitment approving authorities. 

c. Programs and projects shall hold cost, schedule and 
technical reserves within the thresholds and report on 
the margins periodically. These reports shall include 
usage and status of the APA and contingency reserves. 

d. For programs required to provide PSR's, as defined in 
GAO Report B-237602, "Project Status Reports" (reference 
(o) ) , the appropriate PAA shall report data necessary 
for preparation of the PSR's to the CFO/Comptroller. 

The CFO/Comptroller shall provide the completed PSR's to 
the appropriate congressional committees. 



CHAPTER 6 


RISK MANAGEMENT 


References 


(a) NASA Technical Manual 100311, Program Risk 
Analysis Handbook, August 1987. 


Risk management comprises purposeful thought to the sources, 
magnitude and mitigation of risk, and actions directed toward 
its balanced reduction. As such, risk management is a 
continuous process that is an integral part of program and 
project management at all levels. This chapter: 

a. Defines NASA policy on risk management, 

b. Defines risk and describes the categories of risk, 

c. Describes the concepts of risk management, 

d. Defines the minimum content that a Risk Management Plan 
must contain, and 

e. Defines the management forums that will review and 
validate a program/project's Risk Management Plan. 

2. POLICIES 

Program/project management shall: 

a. Plan and implement a disciplined approach to risk 
management throughout the program/project life cycle by 
preparing and maintaining a Risk Management Plan, 

b. Support management decision making by providing 
integrated risk assessments (i.e., taking into account 
technical, programmatic, supportability (including dual 
sources) , cost and schedule concerns) , 

c. Communicate to NASA management and all program/project 
personnel the significance of assessed risks and the 
decisions made with respect to them. 

3. PROCESSES 

a . Risk Definition/ Categories . 

(1) Risk Definition . Risk is defined as the likelihood 
of an undesirable event occurring and the severity 
of the consequences of the occurrence. 
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RISK CATEGORIES 

TECHNICAL 

PROGRAMMATIC 

SUP PORT AB I L I T Y 

COST 

SCHEDULE 

Physical 

Properties 

Material 

Availability 

Operability 

Sensitivity to 
Technical Risk 

Sensitivity to 
Technical Risk 

Material 

Properties 

Single Source 
Suppliers 

ilHfl 

Sensitivity to 

Programmatic 

Risk 

Sensitivity to 

Programmatic 

Risk 

Radiation 

Properties 

Personnel 

Availability 

Reusability 

Sensitivity to 
Support ability 
Risk 

Sensitivity to 
Suppo rt ab i 1 it y 
Risk 
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Training 

Sensitivity to 
Schedule Risk 

Sensitivity to 
Cost Risk 

Integration/ 

Interface 

Interprogram 

Conflicts 

Operations & 

Support 

Equipment 


Degree of 
Concurrency 

Software 

Design/Errors 

Security 

Spares 

Estimating 

Error 

Number of 
Critical Path 
Items 

Reliability 

Environmental 

Workforce 

Economic 

Estimating 


Safety 



Fault 

Detection/ 

Tolerance 


Operating 

Environment 



Impact 


Communication 

Problems 


Labor Strikes 


Requirement 

Changes 


International 

Involvement 



System 

Complexity 


Unique/Special Funding 
Resources Profile 


Hardware Aging 


Manufacturing Multicenter 
Processes Involvement 


Quality Multiagency 

Involvem 

ent 


Considerations Inflation Errors 

Critical 

Facilities 

Inter- 

operability 

Considerations 



Table 6-1 . Typical Sources of Risk 


(2) Risk Categories . Program/project risk can be 
segregated into five categories: 

(a) Technical 

(b) Program, matic, 

(c) Supportabilit y , 
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(d) Cost, and 


(e) Schedule. 

(3) Understanding and classifying a risk into one or 

more of the five categories requires an examination 
of the sources of the risk. Although it is not 
always easy to determine to which category a 
particular risk belongs, understanding the sources 
of risk and the associated impact area(s) are 
critical if risk is to be managed effectively. 

Table 6-1 depicts typical risk sources by risk 
category . 

b . Concepts of Risk Management . 

(1) Risk management is a continual process that is an 
integral part of project planning and management 
and is updated as new information becomes 
available. Some of the more obvious times for 
revisiting risk issues include: 

(a) In preparation for major decision points and 
program/project milestones, 

(b) In preparation for and immediately following 
technical reviews and audits, 

(c) Concurrent with review and update of 
program/project changes and impacts (design 
changes, test successes or failures, etc.), 
and 

(d) In preparation for budget reviews. 

(2) As shown in Figure 6-1, there are four elements 
that make up the risk management process. These 
four elements are overlapping activities that span 
the program/project life cycle as shown in Figure 
6-2 and described below. 

(a) Risk Planning . The first element of the risk 
management process is risk planning. The 
purpose of risk planning is to force organized 
purposeful thought to eliminating, minimizing, 
recognizing or containing the effects of 
undesirable occurrences during the 
program/project life cycle. A Risk Management 
Plan is required to communicate the plan for 
managing risks. 
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Figure 6-1 . Risk Management Structure Diagram 

PROJECT PROJECT 

WCEPTION COMPLETION 


Typical 
Allocation 
of Effort 



Figure 6-2. Risk Management Process Time Phasing 

(b) Risk Identification and Characterization . The 
second element of the risk management process 
is to identify and characterize 
program/project risks. The objective of this 
step is to understand what uncertainties the 
program/project faces, and which require 
greater attention. This is accomplished by 
categorizing (in a consistent manner) 
uncertainties by the likelihood of occurrence 
(e.g., high, medium or low), and by the 
severity of consequences. This categorization 
forms the basis for ranking uncertainties by 
their relative riskiness. This may be 
depicted using a risk diagram (an example is 
shown in Figure 6-3) . Uncertainties with both 
high likelihood and severely adverse 
consequences are ranked higher than those 
without these characteristics. The primary 
methods used in this process are qualitative; 
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hence, this step is sometimes called 
qualitative risk assessment. The output of 
this step is a list of significant risks (by 
phase) to be given specific management 
attention . 



Consequences 


Figure 6-3. Risk Diagram 

(3) Risk Analysis . The third element of the risk 
management process is quantitative and 
probabilistic. In some programs/projects, 
qualitative methods (as in (2), above) are adequate 
for making risk management decisions; in others, 
these methods are not sufficient to understand the 
problem, or to allocate scarce risk reduction 
resources. Probabilistic risk analysis is the 
process of quantifying the likelihood of 
occurrence, consequences of potential future 
events, as well as attendant uncertainties. The 
program/project manager needs to decide if risk 
identification ana characterization are adequate, 
or if probabilistic risk analysis is needed to 
support decision-making. In making that 
determination, the program/project manager needs to 
balance the possibly higher cost of probabilistic 
risk analysis against the value of its benefits. 

(4) Risk Mitigation and Tracking . The fourth element 
of the risk management process is risk mitigation 
and tracking. Risk mitigation is the formulation, 
selection and execution of strategies designed to 
economically reduce risk. Tracking the 
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effectivenss of the strategies is also considered 
part of risk mitigation. Risk mitigation is often 
a challenge because efforts and expenditures to 
reduce one type of risk may increase another type. 
The ability (or necessity) to trade one type of 
risk for another means that the program/project 
manager and all personnel working the 
program/project need to understand the systemwide 
effects of various strategies in order to make a 
rational allocation of resources. 

c. Risk Management Techniques . Techniques have been 

developed for each area of the risk management process. 
The program/project manager needs to choose the 
techniques that best fit the unique requirements of 
his/her program/project. Table 6-2 illustrates a few of 
the many techniques available to the program/project 
manager . 


RISK IDENTIFICATION 
AND (QUALITATIVE) 
CHARACTERI ZAT I ON 

RISK ANALYSIS 
(QUANTITATIVE & 
PROBABILISTIC) 

RISK MITIGATION AND 
TRACKING 

Project Team 
Assessments 

Decision Analysis 

Watch Lists/ 
Milestones 

Expert Interviews 

Expert Interviews 

Contingency Planning 

Independent 
Assessment (Cost, 
Schedule and 
Technical) 

Probabilistic 
Network Schedules 
(e.g., PERT) 

Descope Planning 

Risk Templates 

Probabilistic Cost 
and Effectiveness 
Models (e.g., Monte 
Carlo Models) 

Parallel Development 
Allocation of 
Resources for 
Strategy 
Implementation 

Lessons Learned From 
Previous Projects 

Fault Trees/Event 
Trees 

Critical Items/ 
Issues Lists & 
Retention Rationale 

FMECAs / FMEAs / 
Digraphs Fault Trees 


Cost /Schedule 
Control Systems and 
Technical 

Performance Measure 
(TPM) Tracking 



Technical 

Margins 



Cost and Schedule 
Reserves 


Table 6-2 . Techniques of Risk Management 

d . Risk Management Plan Content . 

The content of the program/project's Risk Management 
Plan may be tailored to the needs of that 
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program/project but shall contain, as a minimum: 

(1) A characterization of all specific risks identified 
for the program/project, including technical, 
programmatic, supportability, cost and schedule 
risks , 

(2) A description of the methodologies and processes 
used to identify, assess and analyze the 
program/project risks, 

(3) A description of the plans for mitigating and 
tracking the program/project risks, including 
appropriate descope plans and technology 
development plans, with supporting rationale, 

(4) A delineation of responsibilities within the 
program/project for the implementation of the risk 
mitigation and tracking plans. 

The Risk Management Plan may be a separate document or 

segmented among other project planning documents. 

e . Risk Management Forums . 

(1) A program/project's Risk Management Plan shall be a 
part of the program/project documentation required 
to support management reviews. 

(2) The NAR Team and the PMC, shall use the Risk 
Management Plan as one of the deciding criteria to 
determine the readiness of a program/project to 
continue into the next phase of the life cycle. 

(3) The NAR Team shall use specific criteria to assess 
and validate the content covered in a 
program/project's Risk Management Plan and shall 
provide to the PMC an assessment of the Risk 
Management Plan along with any recommendations for 
the PMC's consideration as part of the 
program/project approval process. In addition, the 
NAR Team shall provide feedback on the Risk 
Management Plan to program and project management 
following completion of the Preliminary NAR and NAR 
and prior to presentation of its findings to the 
PMC. 
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CHAPTER 7 


ENGINEERING 


The policies and processes presented in this chapter establish 
a common frame of reference for developing program/project 
plans in the engineering disciplines. 

The policies and processes are organized and presented as 
follows : 

SECTION SUBJECT 

A Design for Fabrication 

B Software Engineering 

C Human Factors 

D Integrated Logistics Support 

Implementation 

E Use of the Metric System 

F Technical Standards 
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CHAPTER 7 


SECTION A 

- DESIGN FOR FABRICATION 


1 . PURPOSE 

These policies and processes establish the basis for 
effectively integrating the design and production engineering 
efforts, so the system and its associated fabrication 
processes can be designed, developed and (where practical) 
tested concurrently. 

2 . POLICIES 

a. The producibility of the design shall be a priority of 
the engineering development effort, particularly when 
products are designed to advance the state of the art. 

b. Rigorous assessment of design and associated fabrication 
process risks and continuous application of effective 
risk reduction measures shall be performed throughout 
all program phases. 

3 . PROCESSES 

As an integral part of detailed design, the fabrication 
processes necessary to produce a system should be identified. 
Fabrication risks should be identified and evaluated, so risk 
abatement can be planned and executed. A risk assessment 
will be made on the capability of contractors and critical 
subcontractors to perform fabrication process and to meet 
cost and schedule commitments. This assessment will include 
consideration of the past performance and quality history of 
the contractor and critical subcontractors. The effects of 
new product or material technology on fabrication are to be 
addressed as part of this effort. This approach: 

a. Identifies effective fabrication processes and product 
design features that enhance producibility. Efforts 
should target design simplification, design for assembly 
and inspectability , design for piece part producibility, 
and design for system integration and test. 

b. Reviews the design's use of hazardous materials and 
investigates use of alternative materials. 

c. Identifies and enhances critical product producibility 
features and associated fabrication processes, such as 
design fabrication tolerances and process control 
limits . 
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d. Develops developmental test strategies and plans that 
provide for proofing or validating fabrication 
processes . 

The fabrication risk assessment will be documented in the 
source selection process. Fabrication risks will be 
subsequently covered in the PDR for long lead-time items, and 
in the CDR for all other items. 

Engineering efforts will be organizationally structured to 
ensure close working relationships between engineering 
design, quality and fabrication functions. 
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CHAPTER 7 


SECTION B 

SOFTWARE ENGINEERING 


References: (a) NMI 2410. 10B, "NASA Software Management, 

Assurance and Engineering Policy" 

(b) NASA— STD— 2 100—91, "NASA Software Documentation 
Standard" 

1. PURPOSE 

T hese policies and processes establish the basis for 

integrating the software elements of a program/project into 
the total technical effort to meet the program cost, schedule 
and performance objectives. 

2. POLICIES 

a. Program/project software shall be integrated into the 
total technical effort in accordance with the 
engineering policies and processes. 

b. Software elements shall be developed and maintained with 
sufficient attention to reliability and maintainability 
policies and processes, as described in Chapter 8. A, to 
meet both performance and life cycle cost objectives. 

3. PROCESSES 

a. A Software Management Plan (SMP) shall be developed and 
finalized no later than the end of Phase B. The SMP 
should identify all software elements (including any 
onboard software for flight systems) necessary to 
perform system operations, or software used to conduct 
the major system-level testing, which might cause 
failure or seriously degrade system performance or 
adversely affect personnel safety. The SMP should 
identify any common software elements and any interfaces 
between software elements. The criticality of each 
software element to safety and to project success should 
also be identified. Based on this, the SMP will 
document : 

(1) Organizational responsibilities and authority for 
software engineering management, control methods 
(e.g., for engineering changes) and technical 
progress tracking methods (e.g.. Technical 
Performance Measurement) to be used. 

(2) The software engineering process, including the 
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system design process, risk management process, 
trade study process, methods and/or models to be 
used for system cost-effectiveness evaluations, 
life-cycle cost management process, and any 
specific tailoring of these processes to the 
requirements of the system. 

(3) Integration and coordination of the required 
technical specialty disciplines into the software 
engineering process. 

(4) Key software engineering milestones and schedules. 

(5) Criteria for the selection of common development 
methods, tools or training. 

(6) Criteria for the selection and use of commercial- 
off-the-shelf software and other inherited 
software . 

(7) Any internal review or inspection processes that 
are in addition to reviews that apply to the entire 
program/project . 

(8) Criteria and processes for incorporating upgrades, 
including: operating systems, languages, processors 
and other software related equipment, applications 
that project software must interface with, and 
applications developed withig the program/project. 

b. Software configuration management should be in 
accordance with the policy and processes of Chapter 5. 

c. Software reliability, maintainability and quality 
assurance should be integrated with the project 
requirements . 
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CHAPTER 7 


SECTION C 
HUMAN FACTORS 


References : 


(a) NASA STD-3000, Volume 1, "Man-Systems 
Integration Standards" 

(b) MIL-H-46855, "Human Engineering Requirements 
for Military Systems, Equipment, and 
Facilities" 

(c) MIL— STD— 1 4 7 2 , "Human Engineering Design 
Criteria for Military Systems, Equipment, and 
Facilities" 


1 . PURPOSE 


These policies and processes establish the basis for 
integrating the discipline of human factors into system 
development efforts. The purposes of human factors include: 


a. Improving system performance, 

b. Reducing workforce, training requirements and operations 
costs, and 

c. Reducing or eliminating critical human performance 
errors . 


2 . POLICIES 

For performance critical and safety critical functions: 

a. Human factors aspects of system designs shall be as 
simple as possible, consistent with the functions 
desired and the expected service conditions. 

b. Systems shall be designed to standardize human factors 
aspects of hardware and software. 

c. The cost effectiveness of alternative human-machine 
interface designs shall be analyzed in order to reduce 
both operational errors and LCC . 

3 . PROCESSES 

a. Human factors requirements should be established during 
Phase B. For crewed flight projects, these requirements 
will usually be tailored from reference (a) . For 
operations facilities, requirements may be derived from 
procedures described in references (b) and (c) , or other 
applicable sources. 


7-C-l 



b. Human factors inputs should be considered in project 
plans, system engineering plans, test plans and 
procedures, and contractual documentation. 

c. Human factors should be integrated into the design, 
development and verification processes. Mockups, 
demonstrations, analyses and simulations should be used 
to validate human-machine concepts. 
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CHAPTER 7 


SECTION D 

INTEGRATED LOGISTICS SUPPORT IMPLEMENTATION 


References: (a) 

(b) 

(c) 

(d) 


(e) 

(f) 

(g) 

(h) 

(i) 

(j) 

(k) 


1 . PURPOSE 


NMI 7500.4, "Acquisition Logistics Policy" 

NMI 6000. 5A, "Transportation Management" 

NHB 6200.1, "NASA Transportation and General 
Traffic Management" 

NHB 6000. ID, "Requirements for Packaging, 
Handling, and Transportation for Aeronautical 
and Space Systems, Equipment and Associated 
Components" 

NHB 5300.4, "(1A-1), "Reliability Program 

Requirements for Aeronautical and Space Systems 
Contractors" 

NHB 5300.4 (IE), "Maintainability Program 

Requirements for Space Systems" 

NMI 5350. 1A, "Maintainability and Maintenance 
Planning Policy" 

NMI 7232. IF, "Master Planning of NASA 
Facilities" 

7234.1, "Facilities Utilization Program" 

NMI 5900. IB, "NASA Spare Parts Acquisition 
Policy" 

MIL— STD-1388, "Logistics Support Analysis" 


These policies and processes establish the basis for 
Integrated Logistics Support (ILS) planning and 
implementation to assure that systems are operable, available 
and affordable for operations. 


2 . POLICIES 

a. Systems design and development shall be accomplished to 
ensure effective and cost efficient support of system 
operations . 

b. NASA programs/projects will ensure effective acquisition 
logistics programs during all phases of the 
program/project life cycle. 

c. Phase E ILS requirements shall be identified, reviewed 
and developed concurrent with system definition, design 
and development. 
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3. 


PROCESSES 


a. Design engineers and logistics engineers should work 
jointly during the design and development process, to 
ensure satisfactory system support and affordable LCC, 
consistent with system requirements and resource 
constraints . 

b. Logistics Support Analysis (LSA) techniques should be 
used to determine the design and management actions 
necessary to ensure system logistics support. LSA 
guidelines are found in the MIL-STD-1388 series of 
documents and should be tailored for application 
consistent with system requirements and resources 
constraints . 

c. ILS processes to define, design, develop and acquire the 
support to meet system operations requirements should 
include definition of support in each of the following 
nine ILS elements: 

(1) Maintenance • The process of planning and executing 
life cycle repair/services concepts and 
requirements necessary to ensure sustained 
operation of system elements. 

(2) Qg.sj.qn Interface . The interaction and relationship 
of logistics with the system engineering process to 
ensure that system element supportability 
influences the definition and design of system 
elements to reduce LCC. 

(3) Technical Data . The recorded scientific, 
engineering, and technical information used to 
define, produce, test, evaluate, modify, deliver, 
support and operate a system or system element. 

(4) Training . The processes, procedures, devices and 
equipment required to train personnel to operate 
and support system elements. 

(5) Supply Support . Actions required to provide all 
the necessary material to ensure the level of 
supportability and usability of systems required to 
meet operational objectives. 

(6) Support Equipment . The equipment required to 
facilitate development, production and operation of 
systems . 

(7) Transportation . The actions, resources and methods 
necessary to ensure the proper and safe movement of 
system elements and materials. Included are the 
packaging, handling and storage of items. 
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( 8 ) 


Human Resources and Personnel Planning . The 
actions required in designing systems and 
determining skills-mix to minimize operator, 
maintenance, engineering and administration 
personnel costs. 

(9) System Facilities . Real property assets required 
to develop and operate system elements. 

e. An ILS Plan should be prepared by the completion of 
Phase B and subsequently maintained. This plan 
documents logistics support concepts, requirements 
responsibilities and trade-off decisions. 

(1) For major systems the ILS Plan should be a distinct 
and separate part of the system documentation. 

(2) For smaller systems the ILS Plan may be integrated 
with other system documentation. 

f. Reliability, maintainability and quality assurance 
requirements and directives are fundamental to ILS 
program management and shall guide ILS approaches to 
systems . 

g. The provisioning of expendable and reparable spares 
should be accomplished through a tailoring of LSA and in 
accordance with the NASA provisioning policies. 
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CHAPTER 7 


SECTION E 

USE OF THE METRIC SYSTEM 


References : 


(a) Executive Order 12770, "Metric Usage in Federal 
Programs" (July 21, 1991) 

(b) NASA Metric Transition Plan (February 10, 1992) 

(c) NMI 8010. 2A, "Use of the Metric System of 

Measurement in NASA Programs" (June 11, 1991) 


1 . PURPOSE 

These policies govern the use of the metric system of 
measurement on major system development programs . 


2. POLICIES 

a. The metric system of measurement, formally known as the 

International System of Units or SI system, as defined 
by ANSI/IEEE Standard 268 (1993), shall be the preferred 

system of weights and measures for major system 
development programs. 

b. New system procurements, grants and business related 
activities shall use the metric system except where such 
use is demonstrated to be impractical or would cause 
significant inefficiencies in performance of NASA's 
mission . 

c. Systems designed and built using inch units may continue 
use of inch units for the life of the system, but shall 
accommodate interfaces with systems built to metric 
units as required. 

d. Where full use of metric units is limited by practical 
considerations, hybrid metric and inch pound design is 
acceptable, if safety and performance would not be 
compromised . 
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CHAPTER 7 


SECTION F 


TECHNICAL STANDARDS 


References : 


(a) OMB Circular A119, "Federal Participation in 
the Development and Use of Voluntary Standards" 

(b) NMI 8010. 2A, "Use of the Metric System of 
Measurement in NASA Programs" 

(c) NMI 8070.6, "Engineering Standards and 
Practices" 


1 . PURPOSE 


These policies and processes concern the role of 
standardization and the use of standardization documents on 
NASA programs . 


a. Standardization, the use of accepted and documented 
practices and materials, shall be used to the maximum 
practical extent, consistent with program objectives, to 
provide a proven technical basis for and to reduce the 
cost and technical risk of systems development and 
operations . 

b. Preference in system design and specification shall be 
given to multi-program standards; development and 
application of program-specific standards will be 
limited to unique program requirements. 


c. Preference will be given to use of non-Government , or 

"voluntary"’ standards where they can be adapted to meet 
program needs, as required by reference (a) . 


d. NASA standardization documents will incorporate metric 
units of measure in accordance with Chapter 7.E and 
reference (b) . 


e. Standards shall not be applied as requirements on 

programs before system options have been fully explored. 

f. Standards shall be tailored as appropriate to meet 

program needs . 


Development and maintenance of NASA standardization documents 
shall be in accordance with reference (c) . 
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CHAPTER 8 


SAFETY AND MISSION ASSURANCE 


The policies and processes presented in this chapter establish a 
common frame of reference for developing program/project plans in 
the safety and mission assurance disciplines. 

The policies and procedures are organized and presented as 
follows : 



Reliability and Maintainability 

Quality Assurance 

Safety 

Environmental Impact 

Nuclear Safety Launch Approval 
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CHAPTER 8 


SECTION A 

RELIABILITY AND MAINTAINABILITY 


References : 


(a) NHB 5300 . 4 (1A-1 ) , "Reliability Program 
Requirements for Aeronautical and Space System 
Contractors" 

(b) NHB 5300.4 (IE), "Maintainability Program 
Requirements" 

(c) NMI 5350. 1A, "Maintainability and Maintenance 
Policy" 

(d) NMI 7500.4, "Acquisition Logistics Policy" 


1 . PURPOSE 


These policies and processes establish the basis for a 
comprehensive effort designed to increase system availability 
and reduce LCC . 


2. POLICIES 

a. Emphasis shall be on: 

(1) Managing the contributions to system reliability 
and maintainability made by hardware, software and 
human elements of the system; 

(2) Preventing design deficiencies (including single 
failure points) , precluding the selection of 
unsuitable parts and materials, and minimizing the 
effects of variability in the fabrication 
processes; and 

(3) Developing maintainable systems, where applicable, 
particularly when this enhances the cost 
effectiveness on a life-cycle cost basis. 

b. Problem/Failure detection, reporting, isolation and 
correction techniques shall be used to support 
development and implementation of systems. 

3 . PROCESSES 

a. Objectives for reliability and maintainability shall be 
defined for all elements of systems that will be used by 
the project. 

b. Predictions and design analyses of the reliability and 
maintainability of all system elements shall be 
conducted as an element of the design process and should 
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be presented at PDR and CDR. Design analysis should be 
conducted to the extent necessary to establish 
acceptable reliability in all operational environments. 

A strategy for accomplishing reliability growth over the 
remaining development period should be developed, and 
should be considered as a factor in the preparation and 
assessment of reliability estimates. 

c. Parts selection guidelines shall be formulated, and 
testing of government or contractor furnished or off- 
the-shelf items should be performed to ensure 
suitability for their intended use. 

d. Reliability derating guidelines should be formulated for 
electronic parts, so if operational environment stresses 
are within guidelines, part reliability will not be 
degraded . 

e. Software maintainability should be enhanced by applying 
modern software engineering practices, such as 
modularization, and by ensuring that software 
documentation is understandable, complete and compatible 
with the software being used. 

f. Where maintainability is needed, the design features 
required for maintainability and the support environment 
for maintainability (e.g., spares, special tooling, 
trained personnel) should be identified by PDR and in 
place for operations prior to completion of Phase D. 

g. Maintainability characteristics, where applicable, 
should be demonstrated in sufficient time to allow for 
cost effective changes to enhance maintainability. See 
Chapter 10 for verification procedures. 
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CHAPTER 8 


SECTION B 

QUALITY ASSURANCE 


References : 


(a) NHB 5300.4 (IB), "Quality Program Provisions for 
Aeronautical and Space System Contractors" 

(b) NHB 5300.4(1C), "Inspection System Provisions 
for Aeronautical and Space System Materials, 
Parts, Components and Services" 

(c) NMI 8010. 1A, "Classification of NASA Payloads" 

(d) NHB 5300.4 (2B— 2) , ''Management of Government 

Quality Assurance Functions for NASA Contracts" 


1 . PURPOSE 


These policies and processes establish the basis for 
implementing the Quality Assurance (QA) processes necessary 
for designing, fabricating, delivering and operating major 
systems. The purpose of these policies and procedures is to 
reduce mission costs while maintaining acceptable risk, 
consistent with the type of mission and the complexity and 
the state of development of available technology. 


2 . POLICIES 


Policies include the following: 

a. Applicable related QA requirements in references shall 
be applied where applicable to NASA system 
programs/projects. 

b. Hardware and software QA activities should be planned 
and implemented in a timely manner consistent with 
project schedules. QA planning and assessment should 
begin before the completion of Phase A in order to 
support Phase B activities. QA activities should 
continue during the definition phase (Phase B) , as well 
as during the design, development and test of hardware 
and software (Phase C/D) . 

c. System hardware and software designs should be analyzed 
and validated for operation in all design environments 
of the system life cycle. 

d. Requirements and verification methods should be 
established to control the design and development 
processes. Verification methods should be selected that 
best represent environmental stress on the developed 
systems without degrading the systems that are tested. 
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Verification methods also should be selected with due 
regard to cost and schedule objectives. 

e. Problems/nonconformances or failures that occur during 
design, development, testing or operations should be 
thoroughly analyzed and corrective action implemented to 
preclude recurrence. 

f. Programs/projects shall perform surveys and analyses of 
their critical single source production and logistic 
support suppliers for essential industrial materials, 
parts, components, systems, and critical facilities. 

This shall also include consumable, hardware, software 
and expendable items. The survey results shall be 
formally documented and made available for Agency use 
(see section 4 and 6) . 

Primary responsibilities for plans, implementation and 
compliance assessment of activities that satisfy QA 
requirements should be explicitly assigned to both the field 
installation's project team and to the respective contractors 
and subcontractors, prior to the issuance of an RFP . These 
requirements should be extended downward by all hardware and 
software developers to the subcontractors and suppliers 
through appropriate contractual documentation. 

3. PROCESSES 

a. QA Planning: 

(1) Assign organizational responsibilities and 
authority . 

(2) Plan the QA effort: 

(a) Define quality tasks and their integration 
within the design, fabrication and test 
processes . 

(b) Provide for the prevention, detection and 
correction of deficiencies or trends that 
could result in unsatisfactory quality. 

(c) Specifically tailor QA processes to 
accommodate project resource constraints. 

(d) Develop a schedule. 

b. QA Implentat ion : 

(1) Identify the QA requirements applicable to designs 
and procedures. 

(2) Train and certify personnel performing hands-on 
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fabrication, assembly and inspection of flight 
hardware . 

(3) Verify that all design elements are adequately 
documented . 

(4) Verify that all design changes are incorporated 
into the hardware and software and that the changes 
are adequately documented. 

(5) Witness and monitor tests, taking into 
consideration the type and criticality of tests. 

(6) Perform QA surveillance, inspection and audit of 
processes that are identified as important to 
system quality, taking into consideration the 
nature and the classification of the resulting 
system . 
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CHAPTER 8 


SECTION C 
SAFETY 


References : 

(a) 

NHB 1700. IB, 
Requirements 

"NASA Safety Policy and 
Document" 


(b) 

NMI 

8710.2, 

"NASA Safety and Health Programs" 


(c) 

NMI 

1800.1, 

"NASA Environmental Health Program 

1. PURPOSE 

(d) 

NMI 

1800.4, 

"NASA Occupational Health Programs 


These policies and processes establish the basis for the 
implementation of a system safety program to eliminate 
hazards or reduce the associated risk to an acceptable level . 

2. POLICIES 

a. The policy for the NASA Safety Program is established by 
references (a) and (b) . For specific health program 
requirements, policy is established by references (c) 
and (d) . Loss of life, personnel injury/illness, 
equipment or property damage or loss, mission/test 
failure, and events that could cause adverse public 
reaction or environmental damage/loss shall be 
prevented . 

b. System safety programs shall be implemented for system 
acquisitions, in-house developments, facility 
design/modifications, and program operations and 
activities. Program-specific requirements should be 
based on the advice of the System Safety Steering 
Committee per NHB 1700.1, Chapter 1. Requirements shall 
be selected based on the potential for personnel injury, 
equipment loss or facility damage, property damage, 
potential impacts to NASA in terms of cost and schedule, 
and public involvement or interest. 

c. Scientific and engineering principles shall be applied 
during design and development to identify and reduce 
hazards associated with system assembly, test, operation 
and support with the objective of designing the safest 
possible systems consistent with mission requirements 
and cost effectiveness. System safety and health hazard 
objectives shall be established in Phase B, and shall be 
used to guide system safety and health hazard control 
decisions and activities. 

d. Program/project managers shall support and maintain a 
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well-defined safety program and organization. Safety 
should be accomplished as an integral part of each 
manager's and supervisor's responsibilities, with timely 
monitoring, surveillance and support from the 
professional safety staff. 

3 . PROCESSES 

a. A System Safety Manager (SSM) should be selected from 
the field installation organization for Safety, 
Reliability, Maintainability and Quality Assurance to 
execute the system safety task. The SSM reports to the 
project manager for project direction and to the field 
installation safety official for policy and technical 
direction. The selected SSM: 

(1) Advises the project manager regarding NASA 
requirements for and status of the system safety 
task . 

(2) Coordinates the system safety effort with systems 
engineering, reliability and quality assurance, 
integration and test, and program management. 

(3) Identifies necessary technical safety requirements 
(including those associated with interfacing 
hardware, software and facilities) and ensures their 
incorporation into specifications and planning 
documents . 

(4) Ensures that submitted Hazard Reports (HRs) contain 
sufficient risk management information based on the 
hazards identified to permit the project manager to 
make informed risk management decisions. 

(5) Reviews system safety tasks, prioritizes safety 
risks, and recommends engineering, procedural or 
other changes necessary to reduce the safety risk. 

(6) Ensures the implementation of a closed-loop process 
for providing traceability and tracking of all 
hazards from identification through resolution. 
Maintain an up-to-date data base of identified 
hazards throughout the life of the system. 

(7) Assists the project manager in establishing the 
Project System Safety Panel, as required. 

(8) Participates in the FRR and Launch Site Readiness 
Review (LSRR) process for operations, supporting 
facilities, and/or flight with the following: 

(a) A safety assessment with emphasis on changes 
to the baseline safety risk/ and 
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(b) A safety certification of readiness with any 
exceptions arising from safety issues and 
concerns . 

(9) Maintains safety oversight of the project tests, 
operations, or activities at a level consistent 
with mishap potential for the life of the system. 

(10) Keeps the Office of Safety and Mission Assurance 
apprised of the status of the system safety tasks, 
particularly problem areas that may require 
assistance from Headquarters. 

b. A Safety Management Plan (SMP) should be prepared in 
Phase B to govern the system safety activities 
throughout the system life cycle. The SMP should be 
approved by the project manager, and should apply to 
contractors when approved. The SMP details the specific 
requirements, tasks, and activities of system safety 
management and engineering required to identify, 
evaluate and eliminate or control hazards. It provides 
a basis for understanding how safety will be applied 
during all phases of the project. The plan integrates 
the various system safety activities with major project 
milestones. The SMP should be reviewed and updated 
prior to commencing Phases C and E. 

c. The total system, including hardware, software, testing, 
manufacturing, operation, support and disposal of 
hazardous by-products shall be evaluated for known or 
potential hazards for the entire system life cycle. 
Actual and potential hazards and associated risks, 
including those related to nuclear materials, 
conventional explosives, propellants and other hazardous 
materials are identified prior to Phase C. 

d. Hazards shall be controlled or eliminated by corrective 
action with the following priorities: 

(1) Eliminate hazardous subsystems within the design; 

(2) Minimize or negate the effects of hazards through 
design techniques; 

(3) Install safety devices; 

(4) Install caution and warning devices; 

(5) Develop administrative controls, including special 
procedures; and 

(6) Provide protective clothing and equipment. 
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e. The system safety task should create and maintain 
documentation that provides ready traceability to the 
baseline safety requirements, criteria and plan 
throughout the system life cycle. All pertinent details 
of the hazard analysis and review shall be traceable 
from the initial identification of the hazard through 
resolution and any updates, unless it is no longer 
applicable . 

f. Contractors may be required to publish and maintain an 
implementing safety plan before the startup of 
operations or commencement of work on deliverable items. 
The contractor safety plan would be approved by the 
project safety manager. 

g. Project managers shall require formal HRs (see NHB 
1700.1, Appendix G) for each hazard with a residual risk 
to be formally accepted before the SAR. All residual 
risks shall be formally accepted in writing to close the 
HR. The process for acceptance of residual risk shall 
be established in the SMP and shall require critical and 
catastrophic hazards be accepted at the program 
manager's level or higher. 
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CHAPTER 8 


SECTION D 

ENVIRONMENT AT, IMPACT 


References : 


(a) National Environmental Policy Act (NEPA) of 
1969, as amended (40 CFR 1500-1508) _ 

(b) Procedures for Implementing the National 
Environmental Policy Act, 14 CFR 1216.3 

(c) NHB 8800.11, "Implementing the Requirements of 
the National Environmental Policy Act" 

(d) Executive Order 11514, Protection and 
Enhancement of Environmental Quality, 

March 5, 1970, as amended by Executive Order 

11991, May 24, 1977 

(e) Executive Order 12114, Environmental Effects 
Abroad of Major Federal Actions, 

January 4, 1979 


1. PURPOSE 


This section summarizes the policies and processes applicable 
to NASA officials at NASA Headquarters and field installations 
concerning their responsibilities under the National 
Environmental Policy Act (NEPA) . 


2. POLICIES 

NASA Headquarters and field installations shall ensure that 
actions and decisions that may impact the quality of the 
environment are environmentally-informed in accordance with 
the policies and procedures of NEPA. The possible 
environmental effects of a proposed action shall be 
considered, along with technical, economic and other factors 
in the earliest planning, as prescribed in NHB 8800.11. NEPA 
requirements also apply to NASA-sponsored programs/projects 
conducted at contractor-owned facilities. 


3. PROCESSES 

a. Project managers shall be responsible for preparation of 
analyses to develop an understanding of potential 
environmental issues and constraints. These analyses 
should be a clear comparative analysis of impacts among 
alternatives to enable the project manager to 
accommodate environmental issues prior to the decision 
to proceed from Phase A to Phase B. 

b. As part of the decision process to initiate Phase C 
(C/D) , program and project managers shall provide any 
environmental documents required in accordance with 
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pertinent federal, state, and local regulations. At 
minimum, an environmental assessment (EA) and/or 
environmental impact statement (EIS) , as appropriate 
shall be completed and circulated prior to preparation 
of the Record of Decision (ROD) describing the selection 
of alternative (s) and the Agency's decision criteria. 

The ROD is a concise public record explaining the 
rationale behind the decision. 

The EA and/or EIS shall include a discussion of all 
reasonable and practicable alternatives, including the 
no action alternative, that were considered in the 
approval decision process along with their respective 
projected environmental impacts. 

The PAA is responsible for preparation of the ROD and 
shall consult with the AA for Management Systems and 
Facilities prior to release of the decision. Phase C 
(C/D) contracts can proceed subsequent to release of the 
ROD . 
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CHAPTER 8 


SECTION E 


NUCLEAR SAFETY LAUNCH APPROVAL 


References : 


(a) Presidential Directive/National Security 
Council Memorandum-25 (PD/NSC-25) , Scientific 
or Technological Experiments with Possible 
Large-Scale Adverse Environmental Effects and 
Launch of Nuclear Systems Into Space, 

December 14, 1977 

(b) NHB 1700.1 (VI— B) , "NASA Safety Policy and 
Requirements Document" 

(c) National Aeronautics and Space Council Report, 
"Nuclear Safety Review and Approval Procedures 
for Minor Radioactive Sources in Space 
Operations, " June 16, 1970 

(d) Nuclear Regulatory Commission (NRC) Rules and 
Regulations, 10 CFR 0-171 


This section summarizes the policies and processes applicable 
to NASA officials at NASA Headquarters and field 
installations concerning their responsibilities under the 
referenced Presidential Directive regarding the launch of 
certain radiological sources or nuclear systems. 

2. POLICIES 

a. In the event that any spacecraft carries more than a 
minor amount of radioactive materials, according to 
reference (c) , or is equipped with nuclear systems, the 
program/project manager shall: 

(1) Provide a safety analysis report identifying the 
radiological risks; 

(2) Proceed through the PD/NSC-25 process to obtain 
approval from the Executive Office of the President 
through the Office of Science and Technology Policy 
(OSTP ) ; and 

(3) Take sufficient measures to ensure against an 
accidental release of radioactive material. 

b. In the event that any spacecraft carries a minor amount 
of radioactive materials, the program manager shall seek 
approval from the NASA Coordinator for the Interagency 
Nuclear Safety Review Panel (INSRP) and report this to 
OSTP, in accordance with reference (b) . 
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c. The program/project manager shall accommodate all 
relevant NRC requirements for ground activities 
involving the handling, storage, use, transportation and 
disposal of radioactive materials prior to launch. 

3. PROCESSES 

NASA officials shall ensure the performance of the following 
procedures for missions that warrant PD/NSC-25 launch 
approval : 

a. Project managers shall provide a nuclear safety launch 
vehicle databook and re-entry analysis as input to the 
development of a Safety Analysis Report (SAR) on the 
radiological source or nuclear system. The databook 
shall contain technical information on the spacecraft, 
launch vehicle and upper stages, potential launch and 
on-orbit accident scenarios, the resulting accident 
environments, locations and their probability of 
occurrence. Current PD/NSC— 25 implementation procedures 
will require initiating databook development activities 
at the start of Phase A, Preliminary Analysis. Final 
databook delivery shall be consistent with DOE's SAR 
input requirements. 

b. The project's SAR will be reviewed by the INSRP . Once 
INSRP's nuclear launch safety evaluation is completed, 
its report is presented to the OSTP . 

c. The NASA Administrator may then elect to request OSTP 
nuclear safety launch approval. 
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CHAPTER 9 


References : 


TEST AND EVALUATION 


(a) NHB 5300.4 (1A), "Reliability Program 
Requirements for Aeronautical and Space System 
Contractors" 

(b) NHB 5300 . 4 ( IB-1 ) , "Quality Program Provisions 
for Aeronautical and Space Systems" 

(c) NHB 5300.4(1C), "Inspection System Provisions 
for Aeronautical and Space Systems Materials, 
Parts, Components and Services" 

(d) NHB 5300.4 (IE), "Maintainability Program 
Requirements for Space Systems" 

(e) NHB 5300.4 (IF), "Electrical, Electronic, and 
Electro-mechanical (EEE) Parts Management and 
Control Requirements for NASA Space Flight 
Programs" 

(f) NHB 5300.4(1G), "NASA Assurance Terms and 
Definitions" 

(g) NHB 1700 . 1 (Vl-B) , "NASA Safety Policy and 
Requirements Document" 

(h) NHB 5300 . 4 (2B-2 ) , "Management of Government' 
Quality Assurance Functions for NASA Contracts" 

(i) NHB 5300.4 (3A), "Requirements for Soldered 
Electrical Connections" 

(j) NHB 5300.4(30, "Requirements for 
Interconnecting Cables Harnesses and Wiring" 

(k) NHB 5300.4 (3H), "Requirements for Crimping and 
Wire Wrap" 

(l) NHB 5300.4(31), "Requirements for Printed 
Wiring Boards" 

(m) NHB 5300.4 (3J), "Requirements for Conformal 
Coating and Staking of Printed Wiring Boards 
and Electronic Assemblies" 

(n) NHB 5300.4 (3K), "Design Requirements for Rigid 
Printed Wiring Boards and Assemblies" 

(o) NHB 5300.4 (3L), "Requirements for Electrostatic 
Discharge Control" 

(p) NHB 6000. ID, "Requirements for Packaging, 
Handling, and Transportation for Aeronautical 
and Space Systems, Equipment and Associated 
Components" 

(q) NSS/GO-1740 . 9B, "NASA Safety Standard for 
Lifting Devices and Equipment" 

(r) NSTS 1700.7, "Safety Policy and Requirements 
for Payloads Using the Space Transportation 
System (STS)" 

(s) NMI 8010. 1A, "Classification of NASA Payloads" 

(t) NAS A- STD— 2 100—91, "NASA Software Documentation 
Standard" 
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(u) NASA-DID-A200, "Test Procedures" 

(v) NASA-DID-R009, "Minimum Contents for Test 
Reports" 

1. PURPOSE 

This chapter establishes policies and processes for verifying 
that NASA space flight and ground systems meet performance 
and^ operational requirements; it includes requirements for 
verification program content, planning, implementation and 
assessment. For Class D payloads, as defined in NMI 8010. 1A, 
or non-NASA payloads flown in NASA programs, it is applicable 
only to the extent required to ensure safety and avoid damage 
to other NASA systems. 

2. POLICIES 

a. Space flight systems, together with related flight 
support equipment, and mission— essential ground support 
equipment, shall be verified by a combination of test, 
analysis, and/or inspection to provide assurance that 
the total system will meet mission performance and 
operational requirements. 

b. Each NASA project shall establish a detailed 
verification program that includes: 

(1) A system verification plan defining the tasks and 
methods required to determine the ability of the 
system, including software, to meet each program- 
level performance requirement and to measure 
specification compliance. General procedural 
guidelines are provided in paragraph 3. 

(2) Documented procedures and controls to ensure proper 
planning, implementation, assessment, configuration 
management, quality assurance and independent 
review of verification activities. 

(3) Timely identification and assessment of program 
risk due to limitations in verification 
capabilities . 

(4) Requirements for documenting and archiving all 
verification procedures, results, supporting 
analyses, deviations and waivers in sufficient 
detail to support independent review and audits. 

c. Testing is the preferred form of verification for NASA 
space systems and shall consist of qualification and 
acceptance tests. 

d. Test requirements shall be traceable to mission 
requirements and system specifications and shall be 
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tailored to reflect system design complexity, mission 
criticality, cost and risk. Simulations must be 
verified to accurately model the instrument in which the 
system will operate. 

e. Test programs shall, to the extent practical, simulate 
all significant environments and demonstrate the ability 
of the system to satisfy performance requirements in all 
planned operating modes. Test programs shall include 
end-to-end testing of the system, including appropriate 
simulation or emulation of interfaces. 

f. Where realistic simulation of natural and induced 
environments is limited by physical or economic 
constraints, these limits and their effects on risk 
shall be identified in the verification plan. 

Augmenting analysis and/or supplemental testing shall be 
performed to demonstrate that performance requirements 
can be met within the limits of acceptable risk. 

g. Where analysis is used in place of or to supplement 
testing, the analytical models shall be validated by 
corroborative testing or by correlation with 
independently derived models. Design factors of safety 
should be increased to allow for increased uncertainty. 

h. Qualification testing shall be conducted to demonstrate 
that design and manufacturing specifications have been 
met and that the resulting system (hardware and 
software) will meet performance requirements with 
adequate margins. Qualification testing shall impose 
load and environmental stresses that exceed the worse- 
case values expected to occur during the complete life 
cycle, including storage, transportation, and handling. 
Life tests and analyses shall be performed on limited 
life and critical components. 

i. Systems that have been tested to qualification levels 
and duration (prototype test) shall not be used for 
flight without certification and, where necessary, 
refurbishment and acceptance testing. 

j. Qualification by similarity may be used in lieu of 
testing. Differences from previously qualified 
systems/system elements must be qualified by 
supplementary tests and analyses. 

k. Acceptance testing shall be conducted to demonstrate 
satisfactory performance of flight systems in the 
expected environment for all flight operational 
conditions and functions, including redundancy, and to 
reveal inadequacies in workmanship and material 
integrity . 
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1 . 


Protoflight systems shall be tested to qualification 
levels for acceptance duration. 

m. Software verification and validation should be 
integrated with flight hardware system verification to 
the maximum extent practical. The system verification 
(both hardware and software) shall be covered in the 
Verification and Validation (V&V) Plan to include the 
activities, methods and degree of independence. (Ref. 
NASA— DID-M400) . Independent V&V shall be considered and 
the program decision to exercise shall be documented in 
a program assurance plan for V&V. 

n. Flight support equipment shall be verified to the same 
qualification and acceptance requirements as flight 
hardware. Mission-essential ground support equipment, 
including ground test facilities, shall be verified to 
ensure that interfaces, environments, and operations 
meet program requirements and do not compromise the 
integrity, performance or life of the flight system. 

o. All configuration changes and/or repairs made subsequent 
to qualification or acceptance testing shall require a 
formal systems engineering impact assessment. Functions 
potentially affected by changes/repairs shall be 
reverified by the same process initially used. 

3. PROCESSES 

a. General . This section establishes procedural guidelines 
for test programs intended to reduce the risk of 
hardware and software failures which may arise from 
deficiencies in hardware design, assembly, fabrication, 
manufacture, rework/repair, and materials, or software 
design, coding, integration or other essentials. The 
objective is to provide program guidance and methodology 
for structuring and administering test verification 
programs to ensure successful operation of NASA 
aeronautical, space and ground systems. 

(1) NASA project managers shall ensure the guidelines are 
addressed when formulating their test verification 
program (s). Test requirements shall be identified in 
the contract /subcontract and/or the task assignments 
between project offices/agencies. It is intended that 
these guidelines be tailored/modified to the specific 
program or project, flight or flight-related hardware 
and software, considering design complexity, state-of- 
the-art, mission criticality and acceptable risk. 

(2) Questions concerning application of this publication to 
specific procurements shall be referred to the NASA 
project office or its designated representative. 
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Test Planning 


The general nature and scope of test programs shall be 
structured from the beginning -to meet the objectives of 
the various life cycle phases beginning with design and 
development . Because some requirements may be 
verifiable by means other than tests (i.e., analysis, 
simulation, pre-existing data), the overall requirements 
should be identified by a systematic examination of all 
applicable verification methods. The ability of tests 
at various levels to provide meaningful verification 
data shall be evaluated. The test program to be 
implemented should be that which: 

(a) Most effectively verifies the requirements are met, 
and 

(b) Does not degrade the developed item. 

The test program shall provide for the proper planning, 
integration, and implementation of the basic program 
test activities, including design qualification testing, 
equipment /software acceptance testing, and 
f light/operational testing under specified environmental 
conditions. Preliminary planning for integrated testing 
during all phases of design, development, production, 
and operations shall be accomplished as early as 
possible . 

A verification matrix shall be used to relate 
requirements to system architecture and to tests to be 
used to verify requirements. Reviews shall be conducted 
to detect overlaps, voids, or redundancies, and to make 
initial project decisions to combine, add or eliminate 
unnecessary tests. The test milestone chart is used to 
present the relationship of all tests and to assess the 
dependencies of the test program when test slippage and 
test facility downtime occurs and tests must be 
rescheduled, or when tests must be added. 

Master Test Plan . This plan shall provide a detailed 
outline of the entire spectrum of test activities 
associated with a NASA system. It should state the test 
concepts; the objectives/requirements to be satisfied; 
test equipment safeguards; the methods, elements, and 
responsible organizations associated with the 
accomplishment; identify the resources required; and 
index other subordinate documents and plans used to 
implement and record the results of the test effort. 

The plan shall contain the supporting/lower-tier test 
plans, procedures, and schedules necessary to define and 
control the total test program. The plan should present 
all the test actions/activities associated with the 
program, from design and development to operational use, 



and their relationship in time, content and 
responsibility. The software test planning shall be 
documented (NASA-DID-M400) and be an integral part of 
the Master Test Plan. The Master Test Plan should 
address the following subjects: 

(1) Test Types, 

(2) Schedules/Flow Diagrams/Milestones, 

(3) Support Requirements, 

(4) Documentation, and 

(5) Management Information System. 

d. -Sps C l f l c Test P Ians . Test plans shall be required for 

each system, subsystem, assembly, item of hardware, 
firmware and software that is to be tested. These plans 
should cover every level of testing on systems, 
equipment, firmware or software. Each plan should 
provide the test concept, objectives, and requirements 
to be satisfied, test methods, elements, responsible 
activities associated with the test, measures required 
and recording procedures to be used. Test plans (both 
hardware and software) shall include a test compliance 
matrix to map the test elements to the appropriate 
system and sub-system specification. Each test plan 
shall be a subset of the Master Test Plan. As a 
minimum, each test plan should normally include the 
following : 

(1) Title Page. 

(2) Introduction: Overview of objectives of the test 

plan, including flow diagrams, milestones, 
personnel participation, locations, environments, 
schedules and security requirements to be observed. 

(3) Flow Diagrams: The flow diagram should present a 

functional description of the test program using a 
block diagram portrayal of the functions and 
sequence that must be met to satisfy the total test 
program. 

(4) Participation: Identifies the NASA, Government and 

contract participation roles and responsibilities. 

(5) Location: Identifies the facilities where the 

testing shall be performed. 

(6) Security: Identifies and states, briefly, any 

security measures or guidelines to be observed. 
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( 7 ) 


Master Test List: List of all tests to be 

performed in the order they are to be performed. 
Each listing should include: 

(a) Test Description. Name and brief description 
of test to be performed. 

(b) Applicable Specif icat ion (s) . 

(c) Test Objectives. Objective of each test 
performed, including the success/failure 
criteria, baseline, duration, and number of 
times each test shall be performed. 

(d) Nonconformance/Failure Reporting. System, 
procedure, documentation for the reporting of 
failures and rejection of material/items. 

(e) Test Equipment. List all equipment and tools 
to be used in the test . 

(f) Instrumentation. Indicates the type and 
recording devices to be used and the number 
and types of parameters to be recorded. 

(g) Data Reduction and Analysis. Describes data 
to be recorded and the data reduction and 
analysis techniques to be used to interpret 
the data. 

(h) Government /NASA Test Facilities. Identifies 
applicable facilities and includes a reference 
to the appropriate facility requirements 
documents . 

(8) Environmental Exposure: Test plan should specify 

the environmental exposure that the hardware will 
be subjected to during this test. 

(9) Validation Procedure: Overview of the procedures 

that NASA or the contractor shall use to validate 
the test results . 

Test Procedures . A test procedure shall be prepared for 
each test to serve as a step-by-step guide for the test 
personnel who shall perform the test and to enable 
others to monitor conduct of the test. It shall 
identify the testing operations to be performed on items 
undergoing developmental, qualification or acceptance 
testing. It identifies items to be tested, the test 
equipment and support required, the test conditions to 
be imposed, the parameters to be measured, and the 
pass/fail criteria to include the tolerances against 
which the test results shall be measured. Necessary 
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test equipment and instruments are specified, the test 
set-up is shown schematically, all required measurements 
and tolerances are listed. Data sheets used to record 
results/item performance in the test are included as 
part of the procedure. Appropriate safety warnings and 
back-out criteria, if necessary, are also included in 
the test plans. The test procedure should contain the 
following : 

(1) Cover and Title Page. 

(2) Record of Changes. Provides for tracking of 

approved changes to the test procedure. 

(3) Table of Contents. 

(4) Applicable Documents. Documents necessary to fully 

develop the test procedure should be listed by 

title, number, date, and source. 

(5) Purpose of Test. 

(6) Test Equipment Identification. 

(7) Any special Support Requirements. 

(8) Step-by-Step Procedure, including: 

(a) Test set-up diagrams, including 
interconnection of test equipment and test 
article; 

(b) Mounting instructions (type of mounting 
hardware and torque values) ; 

(c) Location of measuring or coupling devices 
(e.g., transducers); 

(d) Input and output instrumentation points; 

(e) Test item operating limits and test conditions 
(e.g., temperature, humidity, cleanliness 
requirements) ; 

(f) Performance parameters to be measured; 

(g) Identification of data to be recorded and 
characteristics to be inspected; 

(h) Step-by-step operations/sequence of testing to 
obtain the required data; 

(i) Identification of steps to be verified before 
proceeding; 
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(j) Assignment of mandatory/hold inspection 
points; 

(k) Details of required or optional nondestructive 
evaluations (x-ray, dye k, visual inspections, 
proof tests, etc.); 

(l) Nonconformances or anomalies (instructions for 
handling) ; 

(m) Procedure deviations (instructions for 
handling) ; 

(n) Sampling procedure details for selection (if 
required by specification or plan) ; 

(o) Caution and safety warnings as appropriate. 

(9) Data Sheets. Data sheets shall be included with 
the test procedure or separately attached at the 
end of the procedure. 

For further guidance on test procedures refer to NASA- 
DID-200, "Test Procedures". 

f. Test Records and Data . Each project office/contractor 
shall prepare, maintain and update the records for each 
item, hardware and software, as a means of documenting 
its continuous history. Each record should be 
identifiable to the pertinent item and shall be 
maintained in chronological order. 

(1) Hardware: Hardware records shall account for all 

fabrication, assembly, adjustments, modifications, 
inspection and test operations, as well as idle 
periods (storage) and movement. Entries shall be 
complete, self-explanatory, and signed, and shall 
include or refer to details such as the following: 

(a) As-Designed Configuration Data: Baseline 

configuration plus approved changes and 
deviations . 

(b) As-built Configuration Data: Parts list, 

drawings, specifications, changes, waivers, 
deviations and identification data. 

(c) Fabrication and Assembly History: Build-up 

and disassembly instructions, repairs, rework, 
adjustments and modifications. 

(d) Inspection and Test Records: Specifications, 

procedures, results and variables data. 
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(e) Nonconformance Summary: Initial review. 

Material Review Board actions, deviations and 
waivers, including appropriate contracting 
officer approvals. 

(f) Cumulative Operating Times or Cycles: Data 
derived from test and maintenance logbooks. 

Software: Software records shall account for all 

functional analyses and modeling, software 
development/test tool selection analyses/ 
demonstration, software design analyses, design, 
coding, integration, modifications (patches, patch 
logs, etc.) inspection and test operations, as well 
as support software, processor, and peripheral 
equipment requirements and set-up. Software 
records shall be documented in accordance with the 
Assurance and Test Procedures Data Item Description 
found in the Software Documentation Standard NASA- 
STD-2100-91, NASA— DID— AO 00 section 4.0. The 
records shall contain but are not limited to: V&V 
objectives, procedures and activities. Entries 
shall be complete, self-explanatory, and signed, 
and shall include or refer to details such as the 
following : 

(a) As-Designed Configuration: Baseline 

configuration plus approved changes and 
deviations . 

(b) As-Built Configuration Data: Version 

Description Document, drawings, 
specifications, changes, waivers, deviations 
and identification data. 

(c) Development and Coding History: Compilation 

system demonstrations, development tool 
demonstrations, firmware design/ val idat ion, 
code analysis, error reduction, development 
testing, and error tracking, rework/recode, 
adjustments and modifications. Software 
documentation verification. 

(d) Inspection and Test Records: Specifications, 

procedures for each level of testing, 
procedures for software documentation 
validation, software tools and simulations, 
results and variables data. 

(e) Nonconformance Summary: Initial review/error 

analyses, software review actions, deviations, 
and waivers, including appropriate contracting 
officer approvals. 



g. 


(f) Cumulative Operating Times or Cycles: Data 

derived from simulation/test equipment setup 
and software operating logs and maintenance 
logbooks . 


Test Reports . The test report documents the results of 
a test performed on a system, subsystem, equipment, or 
component, the findings, and the analysis performed to 
determine achievement of the design, developmental, 
fabrication, acceptance, quality conformance or 
environmental performance objectives specified in 
related specifications, standards, or contract work 
statements. The report describes the test performed and 
is used to document compliance. All tests shall be 
documented by test reports within a few weeks of 
completion. Tests stretching over several months shall 
be reported at intervals. The content of the report 
shall be tailored consistent with the testing 
requirements and the program phase. The test report 
should normally contain this information: 


(1) Cover and Title Page 

(2) Table of Contents 

(3) Purpose of Test 

(4) Complete Identification of Item Tested/ Inspected 


(5) Summary 

(a) Discussion of significant test results, 
problems encountered, observations, 
conclusions and recommendations, 

(b) Proposed corrective actions and schedules, 

(c) Identification of deviations, departures or 
limitations encountered, 

(d) Tables, graphs, illustrations or charts to 
simplify summary data. 

(6) Authentication 


(a) Authentication of Test Results: Statement 

that test /inspection was performed on a 
properly configured hardware/software in 
accordance with applicable specifications, 
test/inspect ion plans, and procedures, and 
that results are true and accurate. Statement 
shall be signed by tester/inspector and 
witnesses as authorized. 
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(b) Authorization of Acceptability: Statement 

that the item tested/inspected passed or 
failed item acceptability requirements. 
Statement shall be signed by authorized 
personnel witnesses. 

For further guidance on test reports refer to NASA- 

STD-2100-91 and NASA-D I D-RO 0 9 . 

h. Quality Actions . The project office/contractor shall 
assure that all aspects of the test program are 
adequately planned, including requirements for 
surveillance and inspection, and that vendor equipment, 
facilities, and documentation necessary to perform the 
test are available to support testing. 

(1) Prior to testing, the project office/contractor's 

quality program personnel shall verify: 

(a) The applicable inspection and current approved 
test documents are available. 

(b) The hardware and software are identified. 

(c) The hardware and software conform to the 
configuration specified in the test procedure. 

(d) The test equipment is calibrated and such 
calibration will be effective and sustained 
during the test period. Production tooling 
should not be used for inspection acceptance 
unless it can be verified, controlled and 
calibrated to the extent necessary to ensure 
the required accuracy and ready detection of 
deficiencies . 

(e) The test readiness status of the article to be 
tested, i.e., inspection history, 
documentation, condition of equipment, open 
nonconformances . 

(f) The test set up is in conformance with the 
approved test procedure prior to start of the 
test . 

(g) The test facility complies with requirements 
established by the test procedure, including 
temperature and/or humidity controls, 
contamination controls and electrostatic 
discharge controls. 

(h) That all safety requirements have been met. 
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(i) 


The tooling and/or fixtures required for the 
test have been validated. 

(j) The personnel are available and have required 
certifications . 

(k) The configuration of any computer software 
used with the test or embedded into the test 
item for the test. 

(2) During testing, the project office/contractor's 

quality program personnel shall: 

(a) Ensure that testing is accomplished in 
accordance with approved test specifications 
and procedures . 

(b) Ensure accurate and complete recording of data 
and test results. 

(c) Document rework, adjustment, repair or 
modifications to the hardware or software 
occurring during the test operation. 

(d) Document all changes to test procedures. 

(e) Ensure that only approved changes are 
incorporated into the test procedures . 

(f) Document nonconformances. 

(g) Ensure that any retest is accomplished in 
accordance with NHB 5300 . 4 ( IB-1 ) , paragraph 
1B703 . 

(h) Ensure that personnel and equipment safety 
constraints are observed. 

(i) Document any discrepancies with test support 
equipment and testing environments. 

(3) Subsequent to testing, the project office/ 

contractor's quality program personnel shall: 

(a) Ensure proper disposition of hardware and 
software . 

(b) Report any additional nonconformances. 

(c) Ensure that corrective actions have been 
accomplished relative to nonconformances. 

(d) Verify that test results and reports are 
accurate, complete and traceable to the tested 
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hardware and software. 


(e) Perform a post-test inspection to identify any 
changes to the article that may have developed 
as a result of the test . 

(f) Ensure approved changes have been incorporated 
into the test procedures/specifications. 

For further guidance refer to NHB 5300.4 (IB-1) . 
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CHAPTER 10 


MISSION OPERATIONS 


Reference: (a) NMI 8430. 1C, "Obtaining Use of Office of Space 

Communications (OSC) Capabilities for Space, 
Suborbital and Aeronautical Missions" 


1. PURPOSE 

This chapter provides implementing policies and processes 
applicable to a wide range of flight programs and projects. 
Mission operations include the definition, development and 
operation of ground systems to train personnel, conduct 
flight missions and to process, analyze, distribute and 
archive data received from flight missions. Flight missions 
include free flying spacecraft, aircraft and payloads. 

2 . POLICIES 

a. Program/project planning at every phase will reflect the 
operational aspects of the mission. Milestone decisions 
will consider the quality and specificity of operations 
planning, consistent with the maturity of the system. 

b. Operations requirements (flight vehicle and ground 
system) will be developed and established early in the 
project life cycle, and assessed at the SRR. Issues 
arising between operations and development organizations 
regarding implementation of requirements will be settled 
in a timely manner by the next higher level of 
management above both organizations. 

c. Operations capability will be designed, developed, 
implemented and maintained in a disciplined way 
resulting in qualified systems, procedures, and 
operations personnel to meet mission requirements. 

d. Personnel training and certification processes shall be 
developed and executed so that planned and contingency 
operations will be conducted safely. 

e. Operations will not be initiated until test and 
simulations establish that the system, personnel and 
procedures are ready to support operations. 

f. Operations reviews will be conducted to demonstrate 
readiness for transition to critical operations. 

g. Mission operations will be defined by clear lines of 
authority and accountability, rigorous security and 
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access controls, and thorough record-keeping. 

3. PROCESSES 

a. Operations Concept . An operations concept for the 
mission must be developed. The operations concept must 
address the following: 

How the entire system works-end-to-end. 

Users and how they use the system, 

Functions performed by the 
spacecraft/ instruments. 

Functions performed by the ground system and 
the products it creates, 

Functions performed by the operators, 

Roles and interface of the various ground 
elements versus the onboard systems/flight 
crew: 

Before a mission/observation/experiment, 

During the mission/observation/experiment, 

and 

— After the mission/observation/experiment, 
Communications services linking the ground 
and flight systems elements, 

- Method and timeliness of data processing and 
distribution. 

Arrangements for data analysis and archiving, 

For flights involving human crew, 
identification of the functions to be 
performed by each member. 

Human versus automated operations, and 

- Safety and quality assurance. 

b. Operations Development . 

(1) Operations systems are developed based on analysis 
of mission objectives and user requirements, as 
well as the operations system's functional, 
performance, interface, verification and operations 
support requirements. These analyses should 
include development of operational scenarios to 
reveal the essential functions and inter- 
relationships among system elements in the course 
of carrying out flight operations. The 
requirements to be placed on the flight project, 
launch vehicle, etc., should be reviewed in the 
SRR, Chapter 2 . 

(2) The results of operations development will include 
the following documentation and will encompass all 
components that comprise the operations system. 

(a) Operations System Specification - This 
document contains the technical and 
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performance requirements for the system, 
verification requirements and operations 
requirements. The specification represents a 
technical agreement between the operations 
system developer and project manager. It also 
establishes the basis for judging the 
technical acceptability of the developed 
system. • 

(b) Ground System Implementation Plans - These 
plans typically include a management plan that 
includes the implementation schedule, a 
detailed time phased cost estimate with 
contingency, and a risk management plan. The 
plans should also include an operations test 
and simulation plan for the end-to-end system, 
post delivery support, a product assurance 
plan, configuration management and data 
management . 

(c) Operations Plans - Operations plans will be 
developed to define the operations phases 
(pre-launch, launch transition, activation and 
checkout, and mature operations) and the 
participating organizations. These plans 
should include an organization and staffing 
plan for operations, including the skill level 
of each position. These plans should also 
include plans for training and maintenance and 
a schedule of the operations activities. 

(d) Operations Procedures - The full complement of 
operations procedures needed for normal 
operations, as well as procedures for 
deployment, activation of backup systems and 
safemode recovery will be documented. 

c. Operations Staff Training and Certification . This 
training and certification, including that for 
astronauts, will be performed in accordance with the 
following : 

(1) Training and certification requirements must be 
defined early and factored into the program plan. 
This includes definition of requirements for 
training tools and their integration with 
requirements for related tools, such as simulators 
for ground test and simulation, flight software 
test beds, et . al . , to avoid redundant efforts. 

(2) A formal premission training and certification 
program will be defined for each flight crew member 
and operations position. Integration, test, and 
simulations should be coordinated in order to avoid 
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redundant efforts. 


(3) Certification tests shall be developed and used to 
validate the application of knowledge in real-time 
judgmental situations. 

(4) Training shall include nominal and appropriate 
contingency operations. 

(5) A post launch regressive training program shall be 
established to ensure continued maintenance of 
adequate technical competencies, and to stay 
abreast of mission changes. 

d. Operations Test and Simulations . 

(1) Operations tests and simulations will be conducted 
as an iterative process that starts with tests at 
the component level and builds to end-to-end 
mission simulations that verify the readiness of 
the systems, personnel and procedures to support 
operations. Tests and simulations will begin early 
enough to enable correction of problem areas that 
must be resolved prior to initiation of operations. 
Sufficiant test and simulation will be conducted to 
allow the project to enter actual flight operations 
with a certified capability and a full 
understanding of any constraints. 

(2) The test process must be tailored for each project. 
Factors to be considered in tailoring the test 
process include use of institutional systems, 
complexity of mission operations, number of 
interfaces in the end-to-end system, and the risk 
class of the pro ject /program. 

(3) Testing starts with interface testing and includes 
compatibility testing, end-to-end testing, mission 
profile testing and mission simulations as follows: 

(a) Interface Tests . These tests validate that 
the elements of the end-to-end data system 
have been implemented to the negotiated 
interface requirements. These tests verify 
that the formats and protocols are correct. 
Test data generators are typically used for 
these tests, although simulated or recorded 
spacecraft data sets can be used. 

(b) Network Compatibility Tests . These tests 
ensures that the spacecraft is compliant with 
the radio frequency interface of the 
supporting networks. The network provides the 
required test tools (e.g., the Compatibility 
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Test Van for the Space Network) . 


(c) Mission Compatibility Tests . These tests are 
performed to ensure that the mission 
operations center can correctly command and 
monitor the spacecraft. These tests include 
the interact ion of the mission operations 
center with the spacecraft, usually during 
spacecraft integration and test. Other 
components of the operational end-to-end 
system should be included in these tests if 
possible . 

(d) End-to-End Tests . These tests exercise the 
complete communication path between the 
spacecraft and the operational ground systems. 
These tests exercise the interfaces of the 
ground system simultaneously. 

(e) Mission Profile Tests . These tests exercise 
all elements of the operational ground system 
with emphasis on data processing and interface 
functions. For this purpose, these tests use 
realistic mission time dynamics in amounts of 
data and the sequencing of events. Simulators 
and recorded spacecraft data are typically 
used to drive these tests. 

(f) Mission Simulations . These simulations are 
the final exercises prior to launch and 
demonstrate that the personnel and procedures 
as well as the data systems are in place and 
complete. Mission simulations exercise 
typical operations as well as critical phases 
of the mission, such as launch, deployment and 
activation. Anomalies should be introduced to 
evaluate personnel readiness and procedures. 
Mission simulations typically use a simulator 
and are augmented by the spacecraft and/or 
recorded spacecraft data. 

e . Operations Reviews . 

(1) Prior to entering Phase E, there are a number of 
operations reviews conducted to ensure that the 
mission is ready to enter Phase E. 

(a) Ground System Review . This review is 

conducted during Phase D to determine that 
Phase D activity is proceeding as planned and 
that the project will be ready to enter Phase 
E on schedule. The review should cover the 
entire ground system (from the receiving 
elements to the end user) and include the 
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ground system status, test plans and ground 
system issues. This review is conducted early 
enough to allow for corrective actions and in 
time to supply prerequisite information for a 
launch minus two year MR as described in 
Chapter 2 . 

(b) Mission Operations Review . This review covers 
the detailed plan on how the project will 
prepare for launch, and conduct the initial 
activation and transition to normal 
operations. The review should include 
schedules, staffing, operations procedure 
development (including contingency 
procedures) , training and certification, end- 
to-end tests and mission simulations, and any 
operations issues. This review is conducted 
early enough to allow for management 
corrective actions and in time to supply 
prerequisite information for a launch minus 
one year MR as described in Chapter 2. 

(c) Pre-Ship Review . This reveiw is conducted at 
the end of the spacecraft integration and test 
phase to verify that the spacecraft is ready 
to be shipped to the launch site. 

(d) Launch Site Readiness Review (LSRR) . The LSRR 
is conducted to verify readiness of the launch 
site equipment, facilities and personnel to 
begin pre-launch operations. The review is 
held at the same time as the Pre-Ship Review. 

(e) Flight Operations Readiness Review . This 
review is conducted to determine the readiness 
of the end-to-end system and its personnel to 
support launch and operations. This review 
should address the results of testing to date, 
any discrepancies or workarounds required to 
support launch and operations, and the status 
of the operations staff and their training. 

The intent of this review is to identify 
problems in time to fix them without holding 
launch . 

(f) Flight Readiness Review (FRR) . For crewed 
missions, an FRR will be held approximately 
two weeks before launch. This review is the 
management decision to proceed with launch. 

It includes a detailed discussion of the 
operations timeline and procedures provided by 
the mission operations element, including 
contingency procedures. Any discrepancies in 
the testing of the elements of the end-to-end 
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systems or in the training and certification 
of operations personnel is identified and 
workarounds are presented. At the conclusion 
of the FRR, the Certification of Flight 
Readiness (COFR) is signed by the NASA and 
contractor project managers, SR&QA managers, 
and the Space Shuttle Director of Operations. 

(g) L— 2 Day Review . This review is conducted at 
launch minus two (L-2) days to certify flight 
readiness. The L-2 Day Review certifies that 
all open work remaining at the conclusion of 
the FRR, action items assigned at the FRR, and 
any problems that develop following the FRR 
have been satisfactorily accomplished and 
closed out and that the mission can be 
conducted safely. A COFR document, similar to 
the one signed at the FRR, is signed at the 
conclusion of the L-2 review. 

(h) L— 1 Day Review . This review is conducted at 
launch minus one day to close out any open 
work resulting from the L-2 Day Review and any 
problems that develop following the L-2 Day 
Review. Launch day weather assessments are an 
important part of the L-l Day Review prior to 
final tanking weather assessment. 

(2) The operations reviews for a project must be 

tailored for that project. Factors influencing the 
timing and formality of the reviews include the 
type of critical operations transition, the 
complexity of the operations, the number of 
elements in the end-to-end system, and the heritage 
of the elements and personnel supporting the 
project . 

f . Operations . 

(1) A clear line of authority and accountability shall 
be established for the conduct of mission 
operations. An official shall be designated to 
which all operations personnel report. This 
official will approve the initiation of operations 
activities, and deviations or changes to 
established procedures, and will normally supervise 
critical operations, such as the recovery from a 
spacecraft safe mode. 

(2) The duties, responsibilities and authorities of 
every member of the operations team must be written 
and understood by all. A well disciplined 
operations organization will properly resist 
informal requests by unauthorized persons, 
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regardless of their rank, to take actions involving 
the spacecraft, flight crew or ground systems. 

(3) Access to operations control rooms and facilities 
shall be limited to authorized members of the 
operations team. Appropriate physical security 
shall be employed at facilities that are directly 
in-line with the conduct of mission operations . 
Appropriate electronic security shall also be 
provided to prevent unauthorized persons from 
interfering (by way of telecommunications) with 
systems used in the conduct of mission operations. 

(4) Detailed planning of pre-launch and non-routine on- 
orbit operations is required. Three distinct 
phases are usually encountered: 

(a) Prelaunch, launch, deployment, rendezvous/ 
docking/undocking, and deorbit - characterized 
by time critical activities and activation of 
subsystems for the first time. These 
operations may require the presence of 
subsystem experts (designers) in the control 
room . 

(b) Post-launch activation and checkout - these 
operations are less time critical but may 
differ considerably from routine operations. 
They may involve a detailed characterization 
of the performance of subsystems and 
instruments . 

(c) Routine operations - those that are performed 
over the course of the mission and do not 
involve safety or complex/time critical 
actions . 

Each of these three phases requires planning as 
necessary to ensure the success of the mission. In 
particular, the time critical operations deserve 
the most attention. 

(5) Records of operations shall be kept as a means for 
later determining what might have gone wrong in the 
event of an anomaly. The records shall consist of 
a log book with entries made by the real-time 
operators on duty, plus electronically created and 
stored records of all commands sent to the 
spacecraft, instructions entered by operators into 
the ground systems, and telemetry data received 
from the spacecraft, all tagged by day and time of 
day . 

(6) In missions involving human flight crew, audio 
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recordings of all voice communications shall be 
kept. For launch and critical flight operations, 
audio recordings of voice communications among 
ground based operators also should be made. 

(7) A system of documenting anomalies shall be 
maintained to ensure that each anomaly is 
appropriately analyzed and the most likely cause is 
determined. An anomaly is any unexpected action of 
the spacecraft, flight crew, ground system, or an 
operator that may indicate a failure of some 
element of the system. The anomaly reports 
constitute the cumulative experience of what has 
changed or been learned over the course of mission 
operations, and is a vital resource in coping with 
future anomalies. 

(8) Policies on data archival and the rights to data 
need to be well known among the flight crew and 
operations team and procedures established to 
ensure that the provisions are respected. 
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CHAPTER 11 


PROGRAM MANAGEMENT COUNCIL 


The PMC is the primary Agency-level forum for addressing planning, 
implementation and management of all major Agency programs and 
projects. The PMC is supported by: 

(1) Ad hoc teams of independent experts who conduct 
independent reviews and provide ICE's in support of PMC 
planning and implementation oversight responsibilities; 
and 

(2) A PPMSG which provides the PMC a mechanism for working 
management policy, process and related issues. 

The PMC reviews and corresponding documentation requirements are 
depicted in Figure 11-1 in terms of the project life cycle. The 
following sections, organized as indicated below, describe each of 
the reviews and establish the detailed policies and processes 
governing Agency-level program/project approval and review. 


SECTION SUBJECT 


A PMC Reviews 

B Program/Project Approval Process 

C PMC Reviews of Program/Project Implementation 


APPENDIX SUBJECT 


1 

2 

3 

4 

5 


Program Management Council Charter 
Program/Project Management Steering Group 
Charter 

Integrated Program/Project Summary 
Non-Advocate Reviews 
Independent Annual Review 
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Figure 11-1. PMC Documentation Requirements and Reviews as Related to 
Life Cycle for Major NASA Projects (by Fiscal Year) 



CHAPTER 11 


SECTION A 

PROGRAM MANAGEMENT COUNCIL REVIEWS 


1 . PURPOSE 

This section defines the reviews conducted by or reported 
through the PMC in support of Agency-level approval and 
oversight of programs and projects. 


a. The PMC shall utilize a formal review process to ensure 
that all programs/projects considered for approval meet 
and fulfill the following decision and management 
criteria, respectively: 

(1) The mission need is consistent with Agency strategic 
planning; 

(2) The program and project plans are in accordance with 
NMI 7120.4 and NHB 7120.5; 

(3) Commercial technology development opportunities are 
maximized; 

(4) The projected cost, schedule, performance, objectives 
and deliverables are reasonable, and a clear baseline 
interweaving these elements is committed to by all 
responsible authorities, before final authority to 
initiate Phase C or C/D; 

(5) Program/project risks and issues are defined and 
updated prior to initiating Phase B or C, 
respectively, and a Risk Management Plan is developed 
in the early stages of a program/project; 

(6) Affordability within the projected Agency budget is 
realistically and favorably projected prior to 
recommending authority to proceed with Phase B and 
subsequent phases . 

b. The PMC shall maintain significant oversight throughout 
the life of major programs/projects to ensure conformance 
with PCAs . 

c. The PMC will prudently exercise authority for special or 
cancellation reviews, as necessary, when unforeseen issues 
arise or thresholds are projected to be exceeded. 
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3. REVIEW REQUIREMENTS 


The PMC review requirements are summarized in Table 11-A-l and 
described below in terms of two categories: reviews conducted 

by the PMC itself, and reviews conducted by other groups to 
provide the PMC with various independent assessments of 
programs and projects. 


CHHRACTKRZ8TIC8 

TYPES | 

Subject 

Major Programs 

Major 

Contracts 

Type 

Decision 

Validation 

Status 

Metrics 

Title 

PPAR 

IAR 

MR 

QSR 

Cont ractor 
Met rics 

Purpose 

Independent , 
in-depth 
evaluation of 
readiness to 
proceed 

Independent 
assessment of 
cost /schedule/ 
performance 
against PCA 
(baseline) 

Independent 
assessment of 
1 aunch/mission 
readiness 

Cost /schedule/ 
performance 
status report 

Cont ractor 
performance 
measu remen t 
report 

Frequency or 


Annually 

L-2 Year 

Quarterly 

Quarterly 

Timing 

PPAR 
Phase B 
readiness 
PPAR 

Phase C/D 
readiness 
Cancellation 

L-l Year 


As needed 





Responsibility 

for 

Preparation/ 

Presentation 

PAA and NAR 
Team 

CFO Appointed 

Independent 

Team 

PAA Appointed 

Independent 

Team 

PAA 

Office of 
Procurement AA 

Outcome or 
Product for 
Administrator 

Recommendation 
for proceeding 
or 

cancellation 

■ 

PCA validation 
or 

recommendation 
for change 

Validation of 
1 aunch/mission 
readiness or 
recommenda- 
tions 
regarding 
delay 

Assessment of 
adherence to 
baseline, 
i ssues 

ident i f ication 

I s sues 
identi f ica- 
tion, 

recommendation 
of major 
cont ract s 


Table 11-A-l PMC Review Types and Characteristics 
a . Reviews Conducted by PMC 

( 1 ) Preliminary Program/Pro iect Approval Reviews 
(Preliminary PPAR's) . Upon PMC Chairperson 
approval of a request by the cognizant PAA, the PMC 
shall meet to review a candidate program/project's 
readiness to proceed to Phase B. The PMC shall 
determine that all Phase A requirements have been 
satisfactorily met. The review will include the 


ll-A-2 









































results of the Preliminary NAR and ICE efforts, and 
will culminate in readiness recommendations to the 
Administrator . 

(2) Program/Proiect Approval Reviews (P PAR 1 S ).- Upon 

PMC Chairperson approval of a request by the 
cognizant PAA, the PMC shall meet to determine that 
the program/project's readiness to proceed to Phase 
C or C/D. The PMC shall determine that all Phase B 
requirements have been satisfactorily met. The 
review will include the results of the NAR and 
corresponding ICE efforts and will culminate in 
readiness recommendations to the Administrator . 

When full rate production of multiple units is 
required, initiation of Phase D shall require an 
additional PMC review and the Administrator's 
approval to proceed, according to this same 
procedure . 

(3) Major Technology and Advanced Development Rev i ew s. 
The Council will review, assess and make 
recommendations regarding major technology and 
advanced development programs. Emphasis will be 
given to commercial benefits after considering 
future mission need, potential for multi-mission or 
multi-program use, potential return on investment 
(in terms of both cost and performance) for both 
Agency and commercial use, readiness to begin the 
proposed phase of R&T development, and the realism 
of the funding profile. 

(4) PCA Validation Reviews . Prior to Phase E, the PMC 
shall annually review a written validation prepared 
by the cognizant PAA concerning program/project 
conformance to the current PCA. The PMC will 
utilize the results of an independent review of the 
PCA validation primarily to ensure adherence to the 
program/project threshold requirements (see section 
3.b. (2) (a)) . The PMC will recommend any changes to 
the PCA or program plans as a result of the 
validation process. The PMC will annually 
determine the need for PCA validation during Phase 
E . 

(5) Quarterly Status Reviews (OSR's) . The PMC will 
meet quarterly to review program/project status. 
These reviews are to focus on performance, cost and 
schedule, as measured against the program's 
baseline plan. In addition, emergent issues and 
concerns should be highlighted. The overall 
objective of the QSR is to answer the question, "Is 
the program 'on track' or, is it heading for 
trouble?" Responses are a key determinant in the 
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need for special reviews of individual 
programs/projects requested by the PMC. 

(6) Cont ractor Metrics Reviews . The PMC shall meet as 
necessary to review the results of contractor 
metrics reporting relative to major contracts. 

Those reviews should result in: 

(a) Identification of issues for consideration by 
the Administrator based on individual 
contractor metrics reports; 

(b) Recommendations of the top contracts to be 
reported; and 

(c) Identification and resolution of issues 
affecting overall program/project policy. 

H) Special Progr am/Proiect Reviews (SPPR's) . The PMC 
may hold SPPR's when warranted. 

(a) Special program/project reviews may include, 
but not be limited to, reviews for 
recommending cancellation or continuation of 
programs and projects, as required, whenever a 
threshold established in the PCA is projected 
to be violated or whenever the PAA or 
CFO/Comptroller projects that the 
program/project EAC exceeds the baseline PCC 
or DCC component of the PCA by more than 15%. 
The QSR, annual PCA validation process, and 
changes to Agency strategic planning will be 
key determinants on the need for these 
reviews. Topics to be covered in an SPPR 
shall, to the extent possible, be identified 
at least 30 calendar days prior to the 
scheduled review, unless a shorter period of 
time is authorized by the Administrator for 
the specific review in question. 

(b) Documentation required for an SPPR shall be 
tailored to the specific requirements of the 
PMC and shall in no case exceed the 
requirements for a PPAR without specific 
authorization of the Deputy Administrator. 

b. Independent Reviews Conducted for the PMC 

Independent reviews provide the PMC with independent 
assessments of programs/projects to support a variety of 
decisions. Specifically, independent reviews will be 
conducted as follows: 
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(1) NAR's During the Program/Proiect (Phases A and B) . 

A NAR provides an independent assessment of a 
program/project's readiness to proceed to the next 
program phase. The findings, issues, concerns and 
recommendations of the Preliminary NAR and NAR 
Reports will be used to support PMC deliberations 
and Administrator decisions on a program/project's 
entry into Phase B and Phase C/D, respectively. 

(2 ) Independent Reviews During Project Implementation 
(Phases C, D and E) . 

(a) Independent Annual Reviews (IAR's) . The PMC 
process to validate the PCA (see section 
3.a.(4)) includes an IAR chartered by the 
CFO/Comptroller conducted to assure compliance 
to the PCA defined thresholds. An IAR is 
required during those years when a NAR is not 
conducted. This independent review is not as 
detailed as a NAR, and generally will require 
a smaller technical team to achieve the 
objective. The CFO/Comptroller will be 
responsible for briefing the results of the 
IAR to the PMC. 

(b) Special Program/Proiect Support Reviews . The 
PMC will charter special teams to support the 
Special Program/Project Reviews conducted by 
the PMC (see section 3. a. (7) ) . 

(c) Mission Reviews (MRs) . These reviews focus on 
the pre-launch, launch and operations phases 
of a program/project (see section 3. (f) of 
Chapter 10) . MRs are conducted at about two 
years and one year prior to launch. The 
cognizant PAA appoints the MR chairperson who 
is responsible for identifying a relevant 
group of independent experts to conduct the 
review. The MR reports are included in the 
appropriate QSR's. 

(d) Other (NAR ' s ) . Upon the direction of the PMC 
Chairperson, other full scale NARs may be held 
for special purposes, such as to develop 
recommendations for the Administrator on 
decisions other than those described above 
(e.g., change in mission objectives, violation 
of commitments in PCA, acquisition strategy 
change, etc . ) 
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4 . 


REVIEW SCHEDULING 


a. Agency planning, the annual Agency budget development 
cycle, and decisions to proceed with major programs are 
necessarily linked at critical times in the fiscal year. 
A nominal timeline for critical scheduling of these 
processes, as it relates to scheduling of PMC reviews, 
is shown in Figure 11-A-l. The focus of this figure is 
on the relationship of various elements of the review 
process and not on actual dates. It is the 
responsibility of the cognizant PAA to assure timely 
requests for either a Preliminary NAR or NAR to support 
PMC reviews and special meetings linked to the Agency 
budget cycle. 

b. Prior to the start of the annual budget cycle, the PMC 
will meet to collectively view all new Phase A efforts 
early in their life and provide guidance to the PAA's on 
the Phase B candidates to be pursued during the budget 
year for potential inclusion in the budget. This review 
will prevent unnecessary resources being expended on 
projects that have no potential of being approved in the 
current cycle. 

c. Individual PPAR's for consideration of approval to 
initiate Phase B or C/D of individual programs/projects 
will be scheduled throughout the year as the 
programs/projects are ready. 

d. An integrated PMC review will be conducted prior to 
submission of the Agency's budget to OMB. This meeting 
will focus on final resolution of affordability for all 
Budget Year Candidates, and programs/projects 
recommended for approval to initiate Phase B or C/D. 

e. PCA validations will be provided by the PAA's for 
ongoing Phase C, D or E programs/projects with their 
annual budget submission. The IAR and presentation to 
the PMC will be conducted after the program/project 
receives its budget authority for the current fiscal 
year and has made necessary adjustments. 
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Figure 11-A-l. Agency Strategic Planning and Budget Development Cycle 
























CHAPTER 11 


SECTION B 

PROGRAM/PROJECT APPROVAL PROCESS 


1. PURPOSE 

This section establishes the policies and procedures for the 
program/project approval process once the PAA has determined 
that the program/project has achieved all objectives of the 
current Formulation Phase (A or B) and has recommended that 
it proceed into the next life cycle phase. 

2. POLICIES 

a. The PMC shall ensure that all major programs and 
projects are consistent with Agency strategic planning, 
affordable, and well-planned up front to reasonably 
assure that the Agency can deliver its commitments on 
time and within budget. 

b. NARs shall be conducted to provide management with 
independent assessments and evaluations of major Agency 
programs/projects to support and verify the readiness 
decision to proceed into Phase B or C/D. 

3. PROCESSES 


a . Endorsement Criteria 

The PMC reviews will focus on the following four basic 

questions that must be satisfied in order for the 

Council to endorse the program/project. 

(1) Is the proposed program/project compatible with 
NASA strategic planning? 

(2) Can the projected implementation resource 
requirements (funding and institutional) be 
accommodated within expected Agency resources and 
does the Agency fully intend to support the project 
through Phase C/D and E? 

(3) Have all requirements of the preceding phase been 
satisfactorily met? 

(4) Is the planning for subsequent phases sufficient to 
ensure a reasonable probability of achieving 
proposed technical, cost and schedule commitments? 
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The basis for answering the above four questions will be 
the MNS, IPS, the proposed Preliminary PCA (if 
applicable) and the NAR report, including an ICE. 

b. Documentation Requirements 

(1) Summary . The documentation required for the 

program/project approval process is identified in 
Table 11-B-l. 


Required 

Documents 

Preliminary PPAR 
(Prior to Phase B) 

PPAR (Prior to 
Phase C/D/E) 

MNS 

X 

X 

IPS 

X 

X 

PCA 


X 

ICE 

X 

X 

NAR Report 

X 

X 


Table 11-B-l Program/Project Approval Process Documentation 

Requirements 

(2) Distribution of Copies . Fifteen copies of the 
documents described in (3) and (4) below are to be 
provided to the PMC Chairperson in time for 
distribution to PMC members no later than five 
working days in advance of the PMC meeting. 

(3) Preliminary PPAR . The documentation for this 
review shall be in accordance with the following: 

(a) The cognizant PAA is responsible for the 
following documents: 

MNS, and 

IPS (Appendix 3) . 

(b) The NAR Team shall be responsible for 
preparing a report on the Preliminary NAR 
regarding validation of data and documentation 
described in Appendix 4 . 

(c) The CFO./Comptroller is responsible for 
documentation of the ICE as part of the 
Preliminary NAR Report. 
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(d) The PMC Executive Secretary will be 

responsible for distributing the upcoming PMC 
meeting agenda to the PMC members together 
with the following enclosures: identification 

of unresolved issues between the NAR Report 
and the PAA's proposal for the program/ 
project; the documents described in (a) 
through (c) above; and the transmittal letter. 

(4) PPAR . The documentation for this review shall be 
in accordance with the following: 

(a) The cognizant PAA is responsible for the 
following documents: 

MNS (validated) , 

IPS (updated) , 

Preliminary PCA with complete set of 
supporting commitment agreements. 

(b) The NAR Team shall be responsible for 
preparing a report on the NAR regarding 
validation of data and documentation described 
in Appendix 4 . 

(c) The CFO/Comptroller is responsible for 
documentation of the ICE as part of the NAR 
Report . 

(d) The PMC Executive Secretary will be 
responsible for preparing the upcoming PMC 
meeting agenda to the PMC members with the 
following enclosures: identification of 
unresolved issues between the NAR and the 
PAA's proposed program/project; the documents 
described in (a) through (c) above, as 
appropriate; and the transmittal letter. 

c . PMC Review Formats 

(1) Preliminary PPAR's . These reviews will be 
conducted in the following format. 

(a) The program manager will present 

program/project data and status in the 
following order: 

Each topic in sequence from the IPS 
executive summary. Sections that are not 
applicable or non-controversial will only 
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be mentioned. 


Recommendations for program/project 
scope, requirements, schedule, 
preliminary cost and corresponding 
threshold control criteria. 

(b) The Preliminary NAR Chairperson will present 
the results in the Preliminary NAR Report in 
the following order: 

Program/project validation results in the 
same order as above; 

ICE; 

Readiness recommendation to proceed to 
the next phase; and 

- Recommendations for program/project 

scope, requirements, preliminary cost, 
and schedule. 

(c) The program manager and NAR Chairperson will 
be allocated 30 minutes each for their 
respective presentations. Following a full 
discussion of the issues, trade-offs, and 
proposed scope, requirements, preliminary cost 
and schedule, the PMC will meet in executive 
session to determine the Council's 
recommendations to the Administrator. 

(2) PPAR 1 s . These reviews will be conducted in the 

following format. 

(a) A primary presenter will selected by the 
cognizant PAA to represent the program/ 
project. In addition, the installation (s) 
representative (s) to the NASA Engineering 
Management Council will be included in the 
presentation. The program/project 
presentation will include the following topics 
in the order listed: 

Status of the program/project; 

Update of all elements discussed in the 
Preliminary PPAR, highlighting deviations 
from the preliminary baseline and reasons 
for deviations; and 

Summary of proposed PCA. 
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(b) The NAR Chairperson will present results of 
the program/project Phase B readiness 
assessment in the following order: 

Program/project assessment results in the 
same order as above; 

ICE; 

Readiness recommendation to proceed to 
the next phase; and 

Any recommendations for changes to 
proposed program/project scope and/or 
performance, schedule, and cost 
requirements, including corresponding 
thresholds . 

(c) The primary presenter for the program/project 
and the NAR Chairperson will be provided 45 
minutes each for their respective 
presentations. Following a full discussion of 
the issues, trade-offs, and proposed threshold 
control requirements for the PCA, the PMC will 
meet in executive session to determine the 
Council's recommendations to the 
Administrator . 

d . PMC Recommendations . 

(1) The Deputy Administrator will be responsible for 
drafting a recommendations memorandum to the 
Administrator within 24 hours, providing the 
Council two days to review and comment on this 
proposed memorandum, and having the final 
recommendations memorandum to the Administrator 
within a total of five days of the PMC meeting. 

The recommendations memorandum will be signed only 
by the Deputy Administrator. 

(2) If the Administrator identifies further issues that 
must be resolved prior to his approval or 
authorization to proceed, the cognizant PAA is 
responsible for resolving the issues in a timely 
manner and responding back through the PMC 
Chairperson for potential PMC review and 
recommendation . 

f . Approvals . 

(1) The Administrator's approval of the MNS will 
constitute approval to initiate Phase B. The 
Deputy Administrator's recommendations memorandum 
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shall be used as a guideline in the conduct of 
Phase B unless directed otherwise by the Deputy 
Administrator or Administrator. 

(2) The Administrator's approval of the Preliminary PCA 
will constitute approval to propose initiation of 
Phase C to OMB and Congress. 

(3) Initiation of Phase C or C/D requires: 

(a) Congressional approval; and 

(b) Administrator approval of an update to the 
Preliminary PCA. 

Upon receipt of congressional approval of the 
budget, the PAA will determine the impact on the 
Preliminary PCA of any change in the budget from 
that submitted and of any accompanying 
congressional direction that changes program 
content or implementation plans. These impacts and 
corresponding revisions to the Preliminary PCA and 
other elements of the program will be prepared and 
presented to the PMC. The Council will then 
develop a recommendation to the Administrator as to 
whether to proceed with a revised program/project 
compatible with the approved budget or to proceed 
with cancellation. The Preliminary PCA will be 
updated as necessary to reflect the Administrator's 
decision. The Administrator's signature on the 
updated PCA constitutes his approval to initiate 
Phase C or C/D and establishes this PCA as 
governing the Phase C/D/E program/project. 


11 -H-6 



CHAPTER 11 


SECTION C 

PMC REVIEWS OF PROGRAM/PROJECT IMPLEMENTATION 


1 . PURPOSE 

During Phases C, D, and E, the focus of the PMC will shift 
from ensuring adequate program planning to verifying that 
commitments are being achieved and that the stated mission 
needs are being met. This will primarily be accomplished 
through a series of reviews of program/project 
implementation . 

2. POLICIES 

a. The PAA shall establish, maintain, and utilize systems 
to accurately evaluate program/project status against 
cost, schedule and technical baselines. Problems or 
projected violations of thresholds will be identified 
and reported in a timely manner. 

b. The PAA shall validate the PCA annually. The validation 
will provide the PAA, and subsequently the PMC, with an 
assessment and evaluation of adherence to technical, 
schedule and cost commitments and status against 
corresponding commitment thresholds. The objective will 
be to assure that technical and programmatic commitments 
covering the life cycle of a program/project are being 
fully met and/or to identify potential problems that 
could threaten the commitments. 

c. An IAR to provide an independent objective assessment of 
the program/project's progress to date, will also be 
conducted. It will cover the current outlook relative 
to original plans and expectations and the adequacy of 
technical and management plans for completing Phases C, 

D and E. This will include an evaluation of existing or 
potential technical problems and proposed solutions 
(including trade-offs) so as to assess whether the PCA 
thresholds are in jeopardy. This assessment shall be 
used by the PMC to evaluate the annual PCA validation 
submitted by the PAA. Conducting a special 
program/project review may, at the PMC's discretion, 
negate the need for a separate PCA validation review for 
that year. However, MR's are not a substitute for the 
annual PCA validation. Independent reviews will be made 
available to the PAA so that he/she may reap the 
benefits from impartial experts with "fresh eyes" taking 
an objective look at status. 
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3. 


IMPLEMENTATION REVIEW REQUIREMENTS 


a . Required Reviews 

(1) Independent Annual Reviews ( IAR 1 s) . The IAR will 

be conducted by a team chartered or 
"institutionalized" by the CFO/Comptroller. The 
IAR Team will be copied on all QSR reports. The 
IAR's focus will be narrower than a NAR and 
generally require a smaller team to achieve the 
validation. The IAR team will: 

(a) Conduct an independent review, assessment and 
validation of all PCA elements for the PMC and 
Administrator as described in Appendix 5. 

(b) Provide the Administrator and PMC an annual 
independent validation of the PCC and DCC 
covering LCC for the program/project. 

(c) Ensure that the program/project thresholds are 
not violated. 

(d) Determine if any program/project deficiencies 
exist that have not been previously reported 
and would result in revised program/project 
projections exceeding thresholds. 

(2) Quarterly Status Reviews (QSR's) . The PMC will 
review quarterly status reports. These reports 
will also be sent directly to the CFO/Comptroller 
for distribution to the IAR Team. 

(3) Special Program/Pro iect Reviews (SPPR's) . Special 
reviews will be conducted as described in Section 
A, 3.g. (1) and (2) of this chapter. The PMC will 
charter a team to conduct a special review based on 
the specific issues to be addressed. These teams 
can range between a full-up NAR to a small, 
relatively focused group, depending on the 
particular issue. 

(4) Mission Reviews (MR 1 si . MR reports are reviewed as 
described in Section A, 4.b.(3) of this chapter and 
3.f. of Chapter 10. A decision on exemption from 
these reviews will be made at the time of 
program/project approval. 

b . Selection of Review Team Chairpersons . 

(1) The CFO/Comptroller will select IAR Team 
chairpersons . 
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(2) The Deputy Administrator shall select SPPR team 
chairpersons . 

(3) The PAA's shall select MR team chairpersons. 

(4) Chairpersons shall not be selected from among the 
sponsoring PAA's office personnel. 

(5) Chairpersons shall not be selected from among the 
host field installation personnel. 

c . Selection of Review Team Members . 

(1) Chairpersons shall select the review team members. 

(2) The IAR Team will include necessary technical and 
support personnel to adequately verify that program 
commitments in the PCA are being met. If 
particular problems or trouble areas are known, 
experts or specialists for those disciplines must 
be placed on the team. In order to eliminate 
coming up "on the learning curve, " the IAR Team 
should include members from the previous cognizant 
NAR Team. To the extent possible, continuity of 
the IAR Team should be maintained. 

(3) For a MR team, the emphasis should be on selecting 
personnel with skill in integration and test, 
launch vehicle and vehicle operations, mission 
operations and data analysis. 

(4) Team members should not be selected from personnel 
within the advocacy chain for a program/project. If 
possible, team members should be selected from 
other than the sponsoring PAA's office or HFI . 

(5) All independent review team chairpersons must 
exercise care during the creation of the review 
team to assure compliance with the applicable 
provisions of the Federal Advisory Committee Act 
and the Federal Property Management Regulations 
Rule on Federal Advisory Committee Management . 

d . Review Timing . 

(1) Independent Annual Reviews (IAR's) . This review 
is timed to the budget process; however, if the 
review is conducted near the time of a major 
pro ject /program milestone, the process must allow 
time for the results to be incorporated into PCA 
validation. The PAA's PCA validation will be 
submitted to the PMC at the same time as his 
overall budget recommendation to the Agency. The 
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e . 


independent review will be conducted as soon as 
practical after the PAA's PCA submission. If a 
program/project continues in Phase B for more than 
one year past execution of a PCA, the PMC will 
determine the necessity of IARs prior to budget 
authority to initiate Phase C. 

(2) Mission Reviews (MR's) . The timing of these 

reviews is generally independent of the NASA budget 
cycle. The timing will be proposed by the PAA to 
coincide with key operational milestones. 


(1) The IAR Team shall prepare a report which addresses 
the current technical, cost and schedule 
commitments, presents the team's assessment of 
their validity, and provides corresponding 
recommendations. The latter shall include any 
proposed changes to the PCA and the rationale for 
these changes. The report shall also include 
minority positions in the event team consensus is 
not obtained. 


(2) The CFO/Comptroller will review the results of all IAR's 
and provide for their subsequent oral presentation to 
the PMC. 
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CHAPTER 11 


APPENDIX 1 

PROGRAM MANAGEMENT COUNCIL CHARTER 


1 . BACKGROUND 

NASA requires a well-defined system of integrated planning, 
approval and implementation for Agency programs to assure 
that the Agency initiates programs consistent with its 
strategic planning and available resources and conducts them 
in accordance with the commitments made for each program it 
initiates. The Agency also requires a forum to involve the 
highest level of program officials in efforts to address 
issues pertaining to PPM policy and implementation. 

2. OBJECTIVE 

The objective of the PMC is to provide an Agency-level forum 
for addressing planning, implementation and management of all 
major Agency programs. It shall support the Deputy 
Administrator in: 

a. Assuring that the Agency functions as an integrated 
system in planning, approving and implementing its 
mission to meet its commitments within available 
resources; 

b. Meeting his/her functional management responsibilities 
including PPM policy and process development, 
maintenance and oversight. 

3. FUNCTIONS 

a . Major System Program/Proiect Formulation and 

Implementation . The PMC will accomplish integrated: 

(1) Planning, approval and status readiness evaluations 
to the Administrator for all candidate major system 
programs and projects; 

(2) Review and assessment of those subsequently 
approved programs and projects from their 
initiation through completion of mission 
operations; and 

(3) Review of affordability and recommendation to the 
Administrator of new program/project initiation and 
changes to approved programs/projects in support of 
the annual budget process. 
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In accomplishing these functions, the Council will 
address the following program/project formulation and 
implementation related matters: 

(1) Compatibility of Phase B candidates with NASA 
strategic planning and with projected resources 
availability (funding and institutional); 

(2) Adequacy of proposed program/project planning and 
management; 

(3) Readiness for initiation of Phase B; 

(4) Readiness to submit new start requests for Phases C 
or C/D; 

(5) Conformance of programs/projects to their PCA's 
through review of program/project status reports 
and independent validations; 

(6) Performance on major contracts; 

(7) Recommended cancellation or continuation of 
programs and projects, as required; and 

(8) Special issues arising in the planning and 
execution of Agency major system programs. 

Technology — and Advanced Development Program Review and 

Assessment . The Council will review, assess and make 
recommendations regarding major technology and advanced 
development programs with emphasis on commercial 
benefits after considering future mission need, 
potential for mult i— mission or multi-program use, 
potential return on investment (in terms of both cost 
and performance) for both Agency and commercial use, 
readiness to begin the proposed phase of R&T 
development, and the realism of the funding profile and 
identified Agency and commercial benefits. 

Progra m /Project Functional Management Support . The 
Council will serve as the Agency's highest level forum 
for addressing issues related to PPM (including 
acquisition) policies, systems and processes. For this 
purpose, the Council's programmatic functions will 
include providing oversight to ensure conformance with 
these Agency policies, systems and procedures. The 
Council will identify needed revisions resulting from 
this oversight and review and assess proposed revisions 
from all sources. 
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MEMBERSHIP 


4 . 


The PMC will consist of the following: 


Deputy Administrator, Chairperson 

Associate Administrator for Advanced Concepts 

and Technology 

Associate Administrator for Space Systems 
Development 

Associate Administrator for Space Flight 
Associate Administrator for Space 
Communications 

Associate Administrator for Aeronautics 
Associate Administrator for Space Science 
Associate Administrator for Life and 
Microgravity Sciences and Applications 
Associate Administrator for Mission to Planet 
Earth 

Associate Administrator for Safety and 

Mission Quality 

Comptroller 

Associate Administrator for Procurement 
General Counsel 


5. OPERATION 

A PMC Executive Secretary will be appointed by the Deputy 
Administrator to support the PMC activities. The PMC 
Executive Secretary will be responsible for preparing the 
PMC's schedules and meeting agendas for approval by the 
Deputy Administrator. All documentation to be distributed to 
the PMC in advance of meetings will be submitted to the 
Executive Secretary. 

As Chairperson of the Council, the Deputy Administrator 
is authorized to convene the Council, as necessary, to 
discharge the responsibilities and perform the functions 
of the Council. Attendance and participation by others 
will be as determined by the Chairperson. The results 
of the Deputy Administrator's assessments will be 
presented to the Administrator in the form of findings 
and recommendations. 
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CHAPTER 11 


APPENDIX 2 

PROGRAM/PROJECT MANAGEMENT STEERING GROUP CHARTER 


1. BACKGROUND 

The Deputy Administrator serves as the Agency functional 
manager for PPM. In order to meet this and other PPM related 
responsibilities, the Deputy Administrator has established 
and chairs the PMC comprised of the program and other 
selected AA's. However, the functional management 
responsibilities of the Deputy Administrator also require a 
support mechanism for addressing PPM policy, process and 
related issues. 

2 . OBJECTIVE AND FUNCTIONS 

The objective of the PPMSG is to support the Deputy 
Administrator in meeting his PPM functional management 
responsibilities through performance of the following: 

a. Development of proposed Agency-level PPM policy 
additions, deletions and revisions for review by the 
PMC; 

b. Assuring development of proposed detailed policies and 
procedures required to implement Agency-level PPM policy 
and their subsequent review and endorsement to the PMC; 

c. Provision of oversight of the PPM Training and 
Development Program and presentation of corresponding 
findings and recommendations to the PMC; 

d. Provision of direction and oversight of all PPM working 
groups; and 

e. Provision of other PPM functional management related 
support as requested by the Deputy Administrator /PMC . 

3 . MEMBERSHIP 

The PPMSG shall be comprised of senior Headquarters and field 
installation personnel from the Agency PPM community. The 
PPMSG Chairperson shall be a Deputy AA of a program office 
with major system development responsibilities and shall be 
appointed by the Deputy Administrator. The other members of 
the PPMSG (including alternates) and an Executive Secretary 
will be selected by the PPMSG Chairperson in consultation 
with the cognizant AA or FID. The Headquarters members will 
be selected from among the offices having major 
responsibilities for system development program management 
and the Offices of the Comptroller, Procurement, and Safety 
and Mission Assurance. These Headquarters members (including 
alternates) shall be at the Deputy AA/Division Director 
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level. Field Installation members (including alternates) 
shall be at the Director For/Deputy Director For level. 

OPERATION 


4 . 


The PPMSG will report to the Deputy Administrator. The PPMSG 
Chairperson is authorized to convene the Steering Group as 
necessary to perform the PPMSG functions. Attendance and 
participation by others will be as determined by the PPMSG 
members except for any executive sessions where attendance 
will be as determined by the Chairperson. Meeting minutes 
will be prepared by the PPMSG Executive Secretary. 
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CHAPTER 11 


APPENDIX 3 

INTEGRATED PROGRAM /PROJECT SUMMARY (IPS) 


This Appendix provides instructions for preparing the IPS in 
support of a PPAR. The IPS is the primary document used to 
facilitate top-level decision making on the readiness of 
programs/projects to proceed into Phase B or Phase C/D. It 
provides a comprehensive summary of program structure, plans, 
status, assessment, and recommendations by the Program Manager and 
PAA. Primary functions of the IPS include: 

a. Summarizing where the program is versus where it should be; 

b. Describing where the program is going and how it will get 
there; 

c. Identifying program risk areas and plans for closing risks; 
and 

d. Providing the basis for establishing explicit program/project 
cost, objectives, schedule, and performance (operational 
effectiveness and suitability) . For the Phase C/D review, 
proposed thresholds will be included. Specific exit criteria for 
the next program/project phase will be recommended. 

The format and content of the IPS are attached. The document 
should not exceed 20 pages in length. 
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INTEGRATED PROGRAM/PROJECT SUMMARY 
(PROGRAM/PROJECT TITLE) 

Provided For: 

Preliminary Program/Project Approval Review 

Program/Project Approval Review 


Recommended By : 

Field Installation Director or Date Organization 

HFI Program Manager 


Program Associate Administrator Date Organization 


IPS Cover Sheet Format /Content 
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INTEGRATED PROGRAM /PROJECT SUMMARY 
(PROGRAM /PROJECT TITLE) 


1 . PROGRAM /PROJECT DESCRIPTION 

A summary level description of the program/project and the 
mission needs to be met. 

2 . BACKGROUND 

a. Describe how the exit criteria in the prior 
recommendations memorandum from the Deputy Administrator 
or as amended by the Administrator were satisfied. 

b. Summarize any subsequent guidance, decisions and 
Congressional actions. 

c. Provide the current program/project and contract (s) 
status of : 

(1) Cost est imate-at-complet ion, 

(2) Schedule, and 

(3) Achieved performance. 

d. Summarize major cost, schedule and performance 
trade-offs made during the previous phase and to be made 
during the next phase. 

e. Program funding status relative to: 

(1) Prior years, 

(2) Current budget, and 

(3) Outyear extended plan for funding program 
completion . 

Include and discuss obligation status for prior and 
current year funding. 

3 . SYSTEM CONCEPT IS) 

a. At the Preliminary PPAR: 

(1) If a new system is proposed, discuss why use of an 
existing system (government or commercial) , or 
product improvement of an existing system was not 
selected . 

(2) For the most promising concept, identify existing 
government or commercial non-development items 
(subsystems) , which will be evaluated for use or 
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possible modification during the next phase, 

b. At the PPAR : 

(1) Describe program/project progress since the 
Preliminary PPAR, including contract performance 
and the results of test and evaluation. 

(2) For the most promising design, identify which 
subsystems, components or materials require new or 
additional development. Discuss why an existing 
government or commercial non-development item 
subsystem, component or material cannot be used. 
Identify supporting analyses. 

4. RESULTS OF ASSESSMENTS OF ALTERNATIVES 

a. Identify all alternatives considered. 

b. Discuss selection criteria and how they relate in 
priority order to the mission need. 

c. Discuss rejected alternatives and reasons for their non- 
selection . 

d. Summarize the cost, relative cost effectiveness, 
schedule, and performance assessment of the most 
promising alternative and the supporting rationale 
relative to the MNS. 

5. ENVIRONMENTAL ANALYSIS 

Summarize any potential impacts to the environment or public 
health and safety. Identify the type of environmental 
analysis conducted. Summarize whether the concept /system 
alternative chosen is environmentally preferable to other 
alternatives. If an environmental impact statement is 
conducted, summarize public response. 

6. PROGRAM STRUCTURE 

Summarize the organizational structure from the cognizant PAA 
through project manager, highlighting the PCA and supporting 
agreement officials. The initial structure and any planned 
evolution should be provided for the life of the project. 

Key approval and authority levels should be highlighted. Top 
level relationships to other organizations must be 
summarized. Key personnel (positions and qualifications) 
should be provided. 

7 . ACQUISITION STRATEGY 

Summarize the acquisition strategy, highlighting the business 
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and contractual management approach designed to achieve 
program objectives within the resource constraints imposed. 

8. CONTROL SYSTEMS AND PROCESSES 

a. Summarize the key program/project control systems and 
processes, including specific metrics to be tracked 
during execution of the phase. 

b. Summarize the key elements of contractor management and 
cost control. 

9. INSTITUTIONAL REQUIREMENTS 

a. Summarize the program/project's technical, management, 
budget and institutional support needed to accomplish 
the program/project on schedule and within budget. 

b. Highlight where Agency augmentation of resources, civil 
service workforce, or existing infrastructure is 
required . 

c. Discuss potential for reducing Agency augmentation needs 
through use of existing outside government and 
commercial resources . 

10 . T.TFR CYCT.E COST ESTIMATE 

Summarize the PCC and the cost estimates for workforce (civil 
service and contractor) and other institutional support 
requirements. Groundrules and assumptions should be stated. 
Include identification of the components of the PCC. 

11 . RISK ASSESSMENT 

a. Provide a succinct summary of the five facets of risk: 
technical (performance, safety, and reliability) , 
supportability (operability and maintainability) , 
programmatic (environment related), cost, and schedule. 
Identify the system component (S) or subsystem (s) most 
directly affected, and the actual or planned specific 
risk reduction efforts or risk management planning being 
undertaken by the program/project manager. 

b. Summarize any additional potential mitigating measures. 

c. Summarize order of descope options if funding 
authorization is reduced from targeted budget authority 
and alternatives that could be exercised in the event 
descoping becomes necessary. Summarize impacts to LCC 
and schedule, as well as performance. 
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12 . 


AFFORDABILITY ASSESSMENT 


Discuss whether or not the proposed program/project can fit 
within the existing funding availability and institutional 
capability in the near-term through the budget horizon 
(approximately five years) and for the entire program life 
cycle. If not, describe what adjustments would have to be 
made to the program to fit within projected resource 
availability, particularly for the upcoming budget year. 
Provide what alternative strategies including offsets, 
tradeoffs, and/or other adjustments, could be employed. 

13. COMMERCIAL TECHNOLOGY DEVELOPMENT 

Summarize the commercial technology aspects and benefits. 

14. EXTERNAL PARTICIPATION 

Summarize the involvement by other government agencies, the 
commercial sector, or foreign governments in the development 
of the program/project being considered. Briefly discuss 
advantages and disadvantages of this participation. Discuss 
the potential use by the commercial sector, other government 
agencies, or foreign governments and potential spin-off 
technology opportunities. 

15 . RECOMMENDATION 

Recommend the proposed acquisition strategy, major trade-offs 
to be made by the milestone decision authroity, proposed exit 
criteria, commitments and threshold values, and whether or 
not to proceed into the next phase. Identify any issues that 
require resolution by the PMC or Administrator. 
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CHAPTER 11 


APPENDIX 4 

NON-ADVOCATE REVIEWS (NAR) 


A NAR provides an independent assessment of a candidate 
program/project's plans, LCC status and readiness to proceed 
to the next phase of the project life cycle. The NAR is 
conducted by a team comprised of highly knowledgeable 
specialists from organizations outside of the advocacy chain 
of the program/project. The findings, issues, concerns and 
recommendations of the NAR Team are used to: 

a. Support the PMC in its deliberative process for 
developing recommendations to the Administrator 
regarding approval or disapproval to initiate Phase B or 
Phase C/D. 

b. Support PAA decision making regarding readiness to 
request that the PMC meet to recommend program/project 
approval or disapproval for entry into the next phase. 

c. Reinforce Agency ability to "deliver on commitments." 

2. POLICIES 

a. Each project requiring PMC endorsement for proceeding to 
Phase B or Phase C/D shall undergo a NAR to provide the 
PMC an independent assessment and evaluation of the 
readiness to proceed. 

b. Each NAR shall provide an independent evaluation of the 

program's/project's: clarity of objectives; 

thoroughness/realism of technical plans and schedules 
and of costs; adequacy of management plans, including 
organizational structure and key personnel credentials; 
and technical complexity. The NAR evaluation of 
technical, cost and schedule risks, and reserve 
allowances in schedule and cost for all life cycle 
program elements, will enable the PMC to answer the four 
basic questions cited in Section B, paragraph 3, of this 
Chapter . 

c. If the program is changed substantially after the NAR, 
then the program must reenter the NAR process. 

3. NAR TEAM SELECTION 

a. The Deputy Administrator shall select the chairperson of 
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the NAR Team. 


(1) The Chairperson shall not be selected from among 
the sponsoring PAA's office personnel. 

(2) The Chairperson shall not be selected from among 
the host project field installation's personnel. 

b. The Chairperson shall select the remainder of NAR Team, 
which shall, at a minimum, consist of 
experts/specialists knowledgeable in the following 
areas : 

(1) Project Management; 

(2) Science and Technical Disciplines; 

(3) Ground Systems Implementation/Mission Operations; 

(4) Program Control; 

(5) Procurement; and 

(6) Resources (from the HQ Office of the Comptroller) . 

c. Team members should not be selected from personnel 
within the advocacy chain for a program/project. If 
possible, team members should be selected from other 
than the sponsoring PAA's office or responsible field 
installation . 

d. To the extent possible, continuity of the NAR Team 
membership should be maintained from review to review. 

e. The Chairperson of the NAR Team must exercise care 
during the creation of the NAR Team to assure compliance 
with the applicable provisions of the Federal Advisory 
Committee Act and the Federal Property Management 
Regulations Rule on Federal Advisory Committee 
Management . 

4. SCHEDULE 

a. The NAR process must allow time for the results to be 
incorporated into the NASA budget process. 

b. To ensure that there is adequate time to conduct the NAR 
and prepare and present results, the following time 
requirements should be accommodated: 

(1) Approximately four weeks are required for: 

Deputy Administrator to select the NAR 
Chairperson, 
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NAR Chairperson to select the NAR Team, 
Program/project staffs to prepare 
presentations , 

NAR Team to review advanced information 
packages ; 

(2) Approximately three weeks are required for: 

NAR Team to conduct the full scale review. 
Program/project staffs to prepare responses to 
NAR open items and requests for additional 
information, 

NAR Team to research special issues/obtain 
additional expert opinions; 

(3) Approximately three weeks are required for: 

NAR Team to prepare report, 

NAR Team to present findings to the cognizant 
PAA; and 

(4) Approximately one week is required to prepare 
program/project responses to NAR findings and 
recommendations . 

c. Presentations to the PMC for a program/project's 

approval to enter into the next phase must be completed 
to allow sufficient time for the recommendation to be 
incorporated into the PAA's budget submission. 

5. PROCEDURES 

To effectively support the PMC in its recommendation for 
progressing into either Phase B or Phase C/D, the NAR Team 
must gain a thorough understanding of the present position of 
the program/project, as well as an understanding of the major 
trade-offs and alternatives explored by the design team. 

a. Advanced Information. The cognizant program/project 
office will compile a representative set of existing 
briefing packages and descriptive reports of the 
program/project. The compilation will be sent to the 
NAR Chairperson for distribution to the team in advance 
of an on-site visit. 

b. Proaram/Proiect Manager's Presentation to NAR Team 
(Minimum Content) . The cognizant program/project 
management will brief the following information to the 
NAR Team : 

(1) Program Background 

(a) Programmatic background - Where the 

program/project fits in NASA strategic 
planning, 
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(b) Historical background - Mission need, 
including identification of stakeholders, 

(c) Scientific background, and 

(d) Technological background. 

(2) Scientific and Technological Objectives 

(a) Primary goals and objectives and their 
rationale (including relation to strategic 
planning) , 

(b) List of key objectives/questions (with 
priorities) that drive mission requirements 
and implementation plans, 

(c) Schedule sensitivities of objectives. 

(3) Program/project documentation status 

(a) Fill out appropriate checklist from Table 
11-4-1 or 11-4-2 (preliminary NAR and NAR 
respectively) . 

(b) Provide similar status of other documents as 
requested or as deemed necessary. 

(4) Implementation Plan 

(a) General. 

(i) Is this program's success dependent on 
other NASA programs? 

(ii) Are there any external dependencies (DoD, 
NOAA, International partners, etc.)? 

(iii) Is there a research/technology transfer 
plan? 

(iv) Will any required funding come from 
outside of NASA? 

(b) Design Requirements 

(i) Summary 

(ii) Feasibility - Phase A or Phase B study 
results 

(iii) Complexity assessment 
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(iv) Trade-off studies/decisions 


Document 

Available 

Schedule 

Date 

Not 

Applicable 

Point of 
Contact 

MNS 





Acquisition 

Strateqy 





AO 





NASA Research 
Announcement 





Phases B/C/D RFP 





Project Plan 





System Performance 
Requirements 





Environmental 

Analysis 





Preliminary 

Systems 

Specification 





Phase A Study 
Report 





LCC Estimate 

i 





Table 11-4-1. Preliminary NAR Document Checklist 
(c) Design 

(i) Technology development and/or 
demonstration requirements, current 
status, and advanced technical 
development plans. 

(ii) Conceptual diagram of flight article. 

( iii ) Subsystem and instrument descriptions 
including as necessary: 

- Requirements 
Configuration/hardware elements 
Heritage/off-the-shelf hardware 
assumptions 

Complexity assessments 

(iv) Resources allocations - summaries by 
subsystem, including margins for: 

Weight 

- Power 
Data Rate 
Computer Memory 
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Document 


Available 


System & Subsystem 

Specifications 

Program and 

Project Plans 

PCA 

Descope Plan 


Schedule 

Date 


Not 

Applicable 


Point of 
Contact 


Mission Success 

Criteria 

Preliminary SRR 

Results 

WBS and WBS 


Dictionary 

Schedules 


Environmental 
Analysis Update 
Interface Control 

Documents 

MOUs, MOAs or 
Other 

Program/Pro ject 

Agreements 

Technology 
Transfer Plan 


Table 11-4-2. NAR Document Checklist 

(v) System integration and test process - 
assumptions and flows 

(vi) Software requirements, sizing, margins, 
heritage, production methods 

(vii) Safety, reliability and quality assurance 

(viii) Support ing systems (launch vehicle, non- 
NASA elements, tracking, etc.) 

(ix) Mission operations and data processing 

(x) Facilities including outfitting 
(d) Management 

(i) Roles and mission assignments 

(ii) Management organization and key personnel 


11 - 4-6 
















(iii) Acquisition strategy 
(e) Funding Resources 

(i) Resources already brought to bear on the 
program . 

(ii) Ground rules and assumptions used as 
basis for LCC estimate. 

(iii) The LCC estimate including all 
program/project unique identifiable costs 
from Phase B through Phase E for: 

a) Development (all program/project 
elements to the subsystem level) 


b) Operations 



1) 

Operations capability 
development 


2) 

Mission operations - through 
end of mission (by function) 


3) 

Data analysis during the 
approved operational lifetime 
(excludes post-mission 
analysis) 

c) 

Cost 

of facilities, including 


outfitting 


d) Launch vehicle (s) 


e) Tracking and data acquisition 

f) Institutional support - excluding 
Civil Service workforce 

g) Other program/project unique costs 

(iv) Type of cost estimate (grassroots, 
analog, parametric, expert advice) 

a) If analog is used, demonstrate 
relevance in measurable manner 

b) Support all estimates with details 

(v) Identify phased funding levels to meet 
objectives 
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(f) Human Resources - Phased workforce to meet 

objectives (contractor and civil service, by 

field installation, by year) 

(g) Implementation Schedule 

(i) Basis for schedule, how time estimates 
were developed 

(ii) How schedule is supported by phased 
resource requirements 

(iii) Schedule sensitivities 

(iv) "Best possible" and "minimum risk" 
schedules 

(h) Program Risk 

(i) Risk assessment 

(ii) Plans for mitigating risk (schedule, 
resources, etc.) 

(iii) Contingency and APA recommendations 
including supporting rationale 


c . NAR Report . 

(1) Format - The format of a brief narrative providing 
an overview/evaluation of each major evaluation 
area followed by specific Findings, Concerns/Issues 
and Conclusions/Recommendations, should be observed 
unless found to be unusable for a particular 
program/project . 

(2) Organization - The report should be organized 
similarly to the IPS (Appendix 3) . Each evaluation 
area should consist of these basic sections: 

- Cover Sheet, 

NAR evaluation (brief narrative) 

Specific Findings, Concerns/Issues, and 
Conclusion/Recommendation. 

(3) Evaluation Areas - The major evaluation areas to be 
reported are: 

(a) Program/Project Description 

(i) Very general description of program 
Goals and objectives 
Hardware proposed to achieve 
objectives 
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(ii) Mission need and relationship to Agency 
strategic planning 


a) 

Role of program 
planning 

vis-a-vis strategic 

b) 

Program/pro ject 

objectives 

c) 

MNS 



(b) Background 

(i) Satisfaction of previous exit criteria 
(if applicable) 

(ii) Maturity and complexity of technologies 

Technical difficulty/tall poles 
Heritage of subsystems and age of 
claimed heritage 
Amount of new design 
Off-the-shelf elements 
New technologies required 
State-of-art breakthroughs required 

(iii) Overall status of the program/project 

a) Funding situation 

b) Schedule performance 

Schedule adequacy 

Critical path analysis - slack 

available 

Associated cost risk 

c) Performance 

d) Problems/issues 

(c) Systems Concepts 

Alternatives with rationale for the selection 
of the most promising alternative 

(i) Alternative approaches studied 

(ii) Trade analyses completed 

(d) Results of assessments of alternatives 

(e) Environmental analysis 

(f) Program Structure 
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(g) Acquisition Strategy 

(h) Control Systems and Processes 

(i) Management 

a) Management approach 

b) Management and organizational 
structure 

c) Center commitments - workforce, 
facilities, resources 

d) Contractors reports/reviews, WBS, 

PMS , etc. 

(ii) Technical 

a) Status of Phase A and B reviews 

b) Program/project oversight and review 
plan 

c) Descope/cost containment plans 

d) Documentation in-place or scheduled 
- see Tables 11-4-1 and 11-4-2 

(iii ) Contractor Management and Cost Control 

(i) Institutional Requirements 

(j) Life-Cycle Cost 

(i) Value of definition investment to date 

(ii) Groundrules and assumptions supporting 
Phase B or Phase C/D entry decision 
estimates for: 

De s i gn / de ve 1 opment 
Operations 

Other life cycle program elements 

( iii ) Program/pro ject cost and schedule 
comparisons phased by Fiscal Year (in 
both constant and real-year dollars.) 

(k) Risk Assessment and Risk Reduction/Descope 
Options 

(i) Technical - Assessment of relative risk 
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levels for entire program/project 
- State-of-the-art challenges 

Risk assessment by program/project 
elements 

(ii) Cost - Reserve requirements/ 
allocation/spread analysis 

(l) Affordability Assessment (provided upon 
specific direction of the PMC) 

(m) Commercial Technology Development (Technology 
Transfer) 

(n) External Participation 

Recommendations - Major recommendations regarding 
the planned program/project scope, requirements, 
cost, schedule and threshold control criteria are 
to be summarized in the final section of the NAR 
Report . 





CHAPTER 11 


APPENDIX 5 

INDEPENDENT ANNUAL REVIEWS (IAR's) 


1. PURPOSE 

An IAR provides an independent examination of a major system 

program after it has been approved and a baseline 

established. The purpose of the review is to: 

a. Advise the PMC as to progress and current status of the 
program regarding meeting its cost, schedule, and 
technical commitments. 

b. Alert the PMC if a program/project threshold is 
projected to be breached. 

c. Assess the adequacy of the annual funding amounts 
included in the Agency budget submission. 

2. POLICIES 

a. It is NASA’s policy that an IAR shall be conducted on 

all programs for which a PCA is in effect. The IAR will 

review and evaluate the cost, schedule and technical 
content of the program over its entire life cycle. The 
IAR shall determine if any program deficiencies exist 
that would result in revised program/project projections 
exceeding thresholds. To accomplish this, sufficient 
information must be provided by all the necessary levels 
of management responsible for execution of the program. 

b. The IAR shall support the deliberative process through 

the PMC by helping it provide realistic status on Agency 

commitments . 

r , . The CFO/Comptroller shall ensure continuity of reviews 
and establish standards for their conduct. 

3. PROCEDURES 

a. Selection of the IAR Team. 

(1) The CFO/Comptroller shall select the IAR 
Chairperson . 

(2) The Chairperson shall select the remainder of the 
IAR team. At a minimum the team will consist of 
members of the Comptroller's staff who have 
experience in cost estimating and program analysis. 
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Additional personnel from engineering and science 
disciplines may be included as well. Membership 
from the original NAR Team should be obtained to as 
great an extent as practical. 

(3) The CFO/Comptroller will ensure that there is a 

continuity of the IAR membership from one year to 
the next for a specific program. 

b. Process 

(1) The IAR Team shall familiarize themselves with the 
program/project prior to initiating the IAR by 
reviewing reports from past NAR's, and IAR's, as 
well as other pertinent documents and reports on 
file in the CFO/Comptroller's office. 

(2) The IAR Team will review the program baseline for 
cost, performance, and schedule at a level of 
detail sufficient to verify conformance to 
commitments and thresholds. It will also review 
the PAA’s control processes and procedures. The 
review will assess progress to date against the 
plan to date and assess risk for completing future 
efforts as planned. The program/project 
presentation to the IAR Team should include at 
minimum : 

(a) Quick overview of program/project background 
for new IAR team members; 

(b) Status and changes since the last NAR or IAR 
regarding the following: 

Primary goals and objectives 
Scientific and technical objectives that 
drive mission requirements and 
implementation plans. 

Implementation Plan described in Appendix 
4, Section 5b(4). (A complete rebriefing 
as required in a NAR is not necessary.) 

(3) A cost assessment will be performed which will 
examine contractor data such as provided by NASA 
533Qs and performance measurement systems. 
Authorized but undef init ized changes, planned 
changes not yet authorized, and any other 
modifications or future requirements will be 
considered. The adequacy of reserve levels should 
be part of the cost assessment. 

(4) A schedule assessment shall be conducted which 
examines milestone achievement against the original 
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baseline, critical path analysis and schedule 
margin adequacy. 


IAR REPORT 


The format /content of the IAR Report to the PMC should be as 

follows : 

a . Current Program Status 

(1) Technical progress made to date against the 
baseline . 

(2) Costs incurred against the baseline. 

(3) Schedule performance against the baseline. 

(4) Funding situation. 

(5) Assessment of PAA proposed changes to the PCA. 

b. Program Evaluation 

(1) An assessment of any changes to the relative risk 
of the program achieving its fundamental mission 
objectives, while adhering to commitments and 
thresholds . 

(2) A comparison of assessed cost, schedule, and 
technical with the corresponding thresholds 
established in the PCA along with a comparison 
against the PAA's current position. 

(3) A comparison of funding requirements by year 
proposed by the PAA with those included in the 
assessment . 

(4) An explanation of key issues identified by the IAR 
Team . 

c . Recommendations 

The report should contain any recommendations to the PMC 
relative to conformance with and required changes to the 
PCA, including any issues that raise concerns on the 
program achieving its fundamental mission objectives 
that may not be reflected in a specific threshold. The 
report should also include any recommendations for any 
additional reviews or individual program briefings that 
the IAR Team deems necessary. This shall specifically 
include a recommendation as to whether or not a CR is 
required . 
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The IAR Report will include minority reports in the 
event team concensus is not attainable. 

5. SCHEDULE AND REPORTING REQUIREMENTS 

a. The IAR shall be conducted once each FY after the 
program/project receives its NOA for the current FY and 
has made necessary adjustments. 

b. The IAR Team will present the results of the review to 
the PAA at least three weeks in advance of submission of 
the report to the PMC to allow adequate time for the PAA 
to prepare responses to IAR Team recommendations and 
issues . 

c. Fifteen copies of the IAR Report will be forwarded from 
the CFO/Comptroller's Office to the PMC Executive 
Secretary for distribution to the PMC. 

d. The CFO/Comptroller is responsible for presentation of 
the IAR results to the PMC. 

e. The Deputy Administrator will prepare a report for the 
Administrator delineating his/her view of the 
program/project progress and status within five working 
days of presentation of the IAR's results to the PMC. 
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APPENDIX A 


DEFINITIONS 


Acceptance Test . A formal test conducted to demonstrate 
acceptability of an item for delivery and flight. It is intended 
to demonstrate conformance to specification requirements and to 
act as a quality control screen to detect deficiencies in 
workmanship, material, processes and quality. 

Acquisition Executive . The senior official in Headquarters 
responsible for integrating and unifying the management process 
for the agency's major system acquisitions and for monitoring 
policy implementation. 

Affordability . The ability of NASA to provide funding and other 
resources to acquire and operate the system as determined by the 
cognizant program office and CFO/Comptroller and confirmed by the 
Deputy Administ rator/PMC . 

Allowance for Program Adjustment (APA) ■ Resources allocated for: 

expansions in project requirements resulting from Headquarters 
approved changes in project objectives or scope; the resolution of 
unforeseen major problems; project stretch outs from agency 
funding shortfalls, etc. These resources are managed by the 
Headquarters program office. 

Cancellation Review (CR) . A review by the Deputy 

Administrator/PMC for the purpose of securing their recommendation 
as to whether to cancel or continue a major system program or 
project which is in Phase C or D and for which the EAC is 
projected by the PAA or the CFO/Comptroller to exceed its PCC or 
the DCC component of the PCC by more than 15 percent. 

Class 1 Competition . A Phase B competition designed to solicit 
proposals for alternative system design concepts to accomplish a 
mission need. 

Class 2 Competition . A Phase B competition designed to solicit 
proposals for a pre-determined single system design concept to 
accomplish a mission need. 

Contingency Resources . Resources allocated to and managed by the 
Project Manager for the resolution of problems normally 
encountered while assuring compliance to the specified project 
scope . 

Development Cost Commitment (DCC) . The cost ceiling established 
by the Administrator for the total costs to be incurred in Phases 
B through D of the project life cycle. 

End-to-End Test . A test performed on the integrated ground and 
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flight system, including its control, stimulation, communications, 
and data processing to demonstrate that the entire system is 
operating in a manner that can fulfill all mission requirements. 

Host F i eld Installa tion (HFI ) . That field installation which is 

responsible for providing the institutional support for the 
program manager function in addition to its responsibilities for 
assigned projects and/or assigned program/project implementation 
support tasks . 

Indepen dent Annual Review (IAR) . An annual review of the status 
of the commitments, performance, cost and schedule commitment in a 
PCA as compared to the program/project baseline and established 
thresholds. IARs are a responsibility of the CFO/Comptroller. 

The results are provided to the PMC. 

Ifl-house Project- A project conducted on-site or in the immediate 
vicinity of a field installation in which essentially most major 
technical, business and management tasks normally performed by a 
prime contractor are performed by the installation's civil service 
staff . 

Ins titutional Resources . The human resources, facilities, 
equipment, information resources, and administrative and program 
support services comprising the NASA institutional infrastructure. 

Integrated Pr ogram/Proiect Summary (IPS) . An IPS is the primary 
decision document furnished by the PAA to the PMC providing a 
comprehensive summary of program/project structure, status, 
assessment, plans, and recommendations by the Program/Project 
Manager and the PAA. 

Level — Funded Program . A Congressional approved program fund which 
allows the peer review process to select and initiate discrete 
projects as accommodated within the overall program funding level. 

Life Test. A test conducted to verify that a system or system 
element can meet performance requirements at required stress 
levels over a specified number of cycles and/or time, including 
storage . 

Life Cycle Costs (LCC) . The total of the direct, indirect, 

recurring, non-recurring, and other related costs incurred, or 
estimated to be incurred, in the design, development, production, 
operation, maintenance, support, and retirement of a system over 
its planned life span. Life-cycle costs are the costs incurred in 
Phases B through E, including development and facility 
construction costs and the project unique costs, such as launch 
vehicles, tracking and data acquisition, and institutional support 
exclusive of civil service workforce costs. Also excluded are the 
undistributed costs of launch vehicles, tracking and data 
acquisition, science, post-Phase E (Operations) data analysis, 
base research and technology (R&T) , focused technology, and the 
non-reimbursable costs of other agencies and governments. 
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Major Program/Proiect . A program/pro ject for system (s) 
development and operation that: 

(1) Is directed at and critical to fulfilling an agency 
mission; 

(2) Entails the allocation of relatively large resources; 
or 

(3) Warrants special management attention. 

The above include but are not limited to: 

(4) All programs/projects for which external agency 
reporting on a regular basis is required; 

(5) All multiple field installation programs; and 

(6) All projects whose DCC's exceed $200 million. 

Margin . The difference between a cost, schedule or technical 
threshold and the current expected value of the parameter 

Mission . A system capability required to accomplish an Agency 
mission or to effectively pursue a scientific, technological, or 
engineering opportunity directly related to an Agency mission. 
These needs are independent of any particular system or 
technological solution. 

Mission Need Statement (MNS ) . The document that establishes the 
justification for undertaking an Agency objective or effectively 
pursuing an opportunity pertaining to an Agency objective. It is 
the document that grants authority to initiate a Phase B effort 
for a candidate project. 

Mission Review (MR) . A review of a flight project conducted for 
the Deputy Administ rator/PMC by a group of independent experts to 
provide an independent assessment of progress toward or readiness 
for mission operations. 

Non-Advocate Review (NAR) . A review of a proposed major system 
project by a non-advocate team appointed by and reporting to the 
Deputy Administrator. The NAR Team is comprised of experienced 
project management, technical, and budget personnel drawn on an ad 
hoc basis from organizations that will not participate in the 
implementation of the proposed project. These reviews provide 
Agency management with independent assessments of the adequacy of 
the project formulation effort. 

Non-Reimbursable Costs . Costs incurred by NASA in program/project 
formulation and implementation efforts performed on the behalf of 
another United States government agency or a foreign government 
and for which NASA is not reimbursed. 
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Phase A ~ Preliminary Analysis . The analysis of a proposed agency 
technical objective or mission and alternative approaches and 
concepts for its accomplishment sufficient to establish need, 
validate feasibility, and prepare an RFP to initiate the 
acquisition process. Phase A begins with PAA approval of a 
request to initiate a Phase A effort (or direction by the PAA to 
do so) and is complete with submission of a proposed MNS to the 
Administrator for approval. 

Phase B - Definition . The effort necessary to understand the full 
range and implications of implementing a proposed project and 
defining the technical and management implementation approaches 
sufficient to make an agency commitment to fully accomplish the 
project technical objective or mission on schedule and within 
budget. Phase B begins with approval of the MNS and ends with 
revalidation of the PCA or Administrator approval of an updated 
PCA necessary to accommodate specific provisions of the full ATP 
from Congress. 

Phase C - Design . The effort required to generate the system (s) 
critical design and test and verification plans. Phase C begins 
with approval of the revalidated or updated PCA and concludes with 
satisfactory completion of the CDR. 

Phase D - Development . The effort required to produce system (s) 
operational readiness. Phase D begins with the satisfactory 
completion of CDR, and for programs where full scale production of 
multiple units is required, with the Administrator's written 
approval. Phase D is complete with acceptance of the system (s) by 
the ultimate user. 

Phase E - Operations . All activities commencing with acceptance 
by the ultimate operator of the system (s) that are necessary to 
accomplish the technical and scientific objectives of the project. 
These include post-launch development, maintenance, planned 
upgrades and selected data analyses. Phase E is complete with the 
retirement of the asset. 

Phased Procurement Strategy . A full and open competition with 
more than one award for Phase B, competitions for subsequent 
phases involving the contractors from the preceding phase with 
award dependent on demonstrated completion of the requirements of 
the previous phase, and by progressively fewer awards for each 
sequential phase. 

Program . A related series of undertakings that continue over a 
period of time (normally years) , which are designed to pursue or 
are in support of a focused scientific or technical goal, and 
which are characterized by: design, development and operations of 
systems; relatively high funding levels; firm schedules; and firm 
technical and/or scientific objectives. Programs are typically 
planned and executed as a series of individual projects or as a 
group of projects to provide a major system capability. 
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Program Associate Administrator (PAA) . The Headquarters official 
responsible and accountable for formulation and implementation of 
a major system program. 

Program Commitment Agreement (PCA) . The contract between the 
Administrator and the cognizant PAA for implementation of a major 
system program. 

Program Cost Commitment (PCC) . The cost ceiling established by 
the Administrator for the life cycle costs of a major system 
program . 

Program Director . The Headquarters official who is responsible 
for the overall direction, control and oversight of a program for 
which implementation responsibility has been delegated to a 
program manager located at an HFI . 

Program Management Council (PMC) . The senior management group 

chaired by the Deputy Administrator responsible for integrated 
Agency-level program planning, recommending approval of proposed 
major system programs, and overseeing their implementation in 
accordance with Agency commitments, priorities, and policies. 

Program Manager (Delegated Imple me ntation Responsibility) . The 

official at or in the vicinity of the HFI who has been delegated 
technical and fiscal resources management responsibility for the 
program . 

Program Manager (Not Delegated Implementation Responsibility) . 

The Headquarters official who is the focal point and serves as the 
external liaison for all Headquarters activities bearing on a 
project or group of projects for which implementation 
responsibility has been delegated to an FID. 

Program Plan . The document that establishes the overall plan for 
implementation of a program. The Program Plan emphasizes the 
management aspects of the program rather than technical 
information and establishes the agreement between the PAA and the 
FID or the program manager at the HFI. 

Program/Project Approval Review (PPAR) . A review of a proposed 
new major system program or project by the Deputy 

Administrator/PMC for the purpose of securing their recommendation 
for : 


(1) Approval to initiate a Phase B effort and its 
relative priority; or 

(2) Approval to proceed to Phase C/D. 

Program/Pro iect Formulation . Those Preliminary Analysis (Phase A) 
and Definition (Phase B) efforts necessary to define the program 
sufficiently to obtain full ATP from Congress to proceed to 
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Program/Project Implementation. 


Proaram/Proiect Implementation . Those Design (Phase C) , 
Development (Phase D) , and Operations (Phase E) efforts necessary 
to accomplish the objectives of an approved program/project. 

Program/Project Management Steering Group (PPMSG) . A group 

comprised of senior Headquarters and field installation 
program/project managers that support the Deputy Administrator/PMC 
in addressing program/project management policy, procedures, and 
related issues. 

Progressive Competition . A phased procurement strategy that 
eliminates the need for a new, formal solicitation for each phase 
of a major system program/project by including a description of 
the subsequent phase competitions planned by the Government in the 
initial solicitation and contracts. 

Project . A defined, time-limited activity with clearly 
established objectives and boundary conditions executed to gain 
knowledge, create a capability, or provide a service as part of an 
overall development program. A project typically encompasses 
design, development, fabrication, test, and as applicable, 
operation of advanced hardware and software, including data 
collection, distribution, and analysis and reporting of results. 

Project Manager . The field installation official who is 
exclusively responsible for project definition and implementation 
to completion within a given set of boundary conditions 
(technical, cost, schedule and organization approach) . 

Project Plan . The document prepared by the field installation 
that establishes the overall plan for implementation of the 
project. The Project Plan emphasizes the management and 
programmatic aspects of the project rather than technical 
information, and establishes the agreement (s) between the PAA and 
the involved FID(s) (Single Field Installation Programs), or 
between the program manager at the HFI and the field installation 
project managers (Multiple Field Installation Programs) . 

Project Status Report (PSR) . A semiannual status report to 
requesting Congressional committees for each major system project 
whose DCC exceeds $200M. The report highlights progress and 
problems and tracks cost, funding, schedule and performance of the 
project . 

Prototype Test . An approach to qualifying space flight systems 
that uses qualification levels and duration's. The test is 
accomplished on flight identical hardware usually not intended for 
flight without further certification. 

Qualification . Determination by a series of documented tests and 
analyses that a part, component, subsystem or system built to 
approved specifications is capable of meeting prescribed 
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performance requirements. 

Qualification by Similarity . The procedure of comparing an item 
to another item having only minor differences in configuration and 
functional characteristics which has been: tested to stress 

levels at least as severe as those specified for the item to be 
qualified; tested under equivalent program controls; manufactured 
by the same supplier using similar processes, materials and 
quality control; and used in a similar application. The item also 
may be identical to one previously qualified and successfully 
flown . 

Risk . The likelihood of an undesirable event occurring and the 
severity of the consequences of the occurrence. 

Reserves . The APA and Contingency resources allocated to the 
cognizant Headquarters and field installation offices 
respectively . 

Supporting Associate Administrator (SAA) . An Headquarters AA 
responsible for committing and providing a system element (s) 
and/or support service needed by a PAA to commit to and implement 
a major system program. 

System . The combination of elements that must function together 
to produce the capability required to meet the mission need. The 
elements include all hardware, software, equipment, facilities, 
personnel, and the processes and procedures needed for this 
purpose . 

Technical Data . Includes all engineering drawings, associated 
lists, process descriptions, and other documents which define the 
physical geometry, material composition, performance 
characteristics, manufacture, assembly, and acceptance test 
procedures . 

Threshold Requirement . A requirement which, if not met, would 
result in the basic mission objective not being achieved, or the 
mission need not being satisfied. 

Undistributed Costs . Costs that cannot be clearly attributable to 
a unique program or project, but are necessary to the formulation 
and implementation of NASA major system programs and projects. 

Verification . A process using test, analysis, and/or inspection 
to confirm that a system and its hardware and software components 
satisfy all specified performance and operational requirements. 
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APPENDIX B 


ACRONYMS 


AA 

AO 

APA 

ASM 

ATP 

C of F 

CDR 

CFO 

CM 

CMR 

COFR 

CR 

CWBS 

DCC 

DOD 

DR 

DRD 

EA 

EAC 

EIS 

FAR 

FMEA 

FID 

FRR 

FY 

GAO 

HFI 

HR 

IAA 

IAR 

ICE 

ILS . 

INSRP 

IPMS 

IPS 

L-l 

L-2 

LCC 

LSRR 

MNS 

MO&DA 

MR 

NAR 

NEPA 

NFS 

NHB 

NMI 

NOA 


Associate Administrator 
Announcement of Opportunity 
Allowance for Program Adjustment 
Acquisition Strategy Meeting 
Authority to Proceed 
Construction of Facilities 
Critical Design Review 
Chief Financial Officer 
Configuration Management 
Contractor Metrics Report 
Certification of Flight Readiness 
Cancellation Review 
Contract Work Breakdown Structure 
Development Cost Commitment 
Department of Defense 
Decommissioning Review 
Data Requirements Description 
Environmental Assessment 
Estimate at Completion 
Environmental Impact Statement 
Federal Acquisition Regulation 
Failure Modes and Effects Analysis 
Field Installation Director 
Flight Readiness Review 
Fiscal Year 

General Accounting Office 
Host Field Installation 
Hazard Reports 

Institutional Associate Administrator 

Independent Annual Review 

Independent Cost Estimate 

Integrated Logistics Support 

Interagency Nuclear Safety Review Panel 

Integrated Program Master Schedule 

Integrated Program/Project Summary 

One year prior to launch 

Two years prior to launch 

Life Cycle Cost 

Launch Site Readiness Review 

Mission Need Statement 

Mission Operations & Data Analysis 

Mission Review 

Non-Advocate Review 

National Environmental Policy Act 

NASA FAR Supplement 

NASA Handbook 

NASA Management Instruction 
New Obligation Authority 
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NRC 

OMB 

ORR 

OSTP 

PAA 

PBS 

PCA 

PCC 

PDR 

PMC 

POP 

PPAR 

PPM 

PPMSG 

PSR 

PSSP 

QA 

QSR 

R&T 

RFP 

RM 

ROD 

RTOP 

SAR 

SDR 

SE&I 

SEB 

SEMP 

SM 

SMP 

SPPR 

SRR 

SSM 

TDA 

TPM 

UPN 

V&V 

WBS 


Nuclear Regulatory Commission 

Office of Management and Budget 

Operational Readiness Review 

Office of Science and Technology Policy 

Program Associate Administrator 

Product Breakdown Structure 

Program Commitment Agreement 

Program Cost Commitment 

Preliminary Design Review 

Program Management Council 

Program Operating Plan 

Program/Project Approval Review 

Program/Project Management 

Program/Project Management Steering Group 

Project Status Reports 

Project System Safety Panel 

Quality Assurance 

Quarterly Status Reviews 

Research & Technology 

Request for Proposal 

Resources Management 

Record of Decision 

Research and Technology Objective and Plan 
System Acceptance Review/Safety Analysis 
Report 

System Design Review 

Systems Engineering & Integration 

Source Evaluation Board 

Systems Engineering Management Plan 

Schedule Management 

Safety Management Plan/Software Management 
Plan 

Special Program/Project Review 
System Requirements Review 
System Safety Manager 
Tracking & Data Acquisition 
Technical Performance Measures 
Unique Project Number 
Verification and Validation 
Work Breakdown Structure 
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